3  Tecniche per la distribuzione di chiavi pubbliche

I protocolli che riguardano la crittografia a chiave pubblica sono tipicamente descritti assumendo, a priori, il possesso di chiavi pubbliche (autentiche) delle parti appropriate. Questo permette piena generalità nelle varie opzioni per l’acquisizione di tali chiavi. 

Esistono metodi alternativi per distribuire chiavi pubbliche con autenticità garantita e verificabile, includendo gli parametri pubblici di Diffie-Hellman per l’accordo su chiave. Nel modello di   spedizione point-to-point su un canale fidato, le chiavi pubbliche autentiche di altri utenti sono ottenute direttamente dall’utente associato attraverso scambio personale o con un mezzo diretto (ad esempio un corriere fidato), che garantisce integrità ed autenticità.  Questo metodo è auspicabile se non usato frequentemente o in piccoli sistemi chiusi. Un altro metodo possibile è scambiare chiavi pubbliche ed informazioni associate, su di un canale elettronico non fidato e fornire autenticazione di queste informazioni attraverso l’uso di funzioni hash (resistenti a collisioni) su un canale indipendente. Gli svantaggi di questo metodo sono: inconvenienza per motivi di tempo, acquisizione non automatica delle chiavi prima di comunicazioni sicure con una nuova parte (sincronizzazione dei tempi) e il costo del canale fidato.              

Nel modello con accesso diretto a file pubblici fidati (registro a chiave pubblica), un database pubblico, la cui integrità   è fidata, potrebbe essere abilitato a contenere il nome e la chiave pubblica autentica di ogni utente del sistema. Questo database potrebbe essere implementato come un registro a chiave pubblica, gestito da una parte fidata. Gli utenti acquisiscono le chiavi direttamente da questo registro. Mentre l'accesso remoto al registro è accettabile su di un canale insicuro contro avversari passivi, in presenza di avversari attivi c'è la necessità di un canale sicuro. Un metodo per autenticare un file pubblico consiste nell'utilizzo di alberi di autenticazione. Un altro modello è quello che usa  un server fidato on-line. Il server fornisce accesso al file pubblico che contiene le chiavi pubbliche autentiche, e restituisce le chiavi pubbliche richieste in una trasmissione firmata; la confidenzialità non è richiesta. La parte richiedente possiede una copia della chiave pubblica di verifica della firma del server, permettendo la verifica dell’autenticità di tali trasmissioni. Gli svantaggi di questo approccio includono: il server fidato deve essere on-line, il server fidato può diventare un collo di bottiglia e i link di comunicazione devono essere stabiliti con entrambi i comunicanti ed il server fidato. Un'altra alternativa prevede l'uso di un server off-line e certificati. In un processo one-time, ogni utente contatta una parte fidata off-line, conosciuta come autorità di certificazione (CA), per registrare la sua chiave pubblica ed ottenere la chiave pubblica di verifica della firma di CA (permettendo la verifica dei certificati degli altri utenti). La CA certifica la chiave pubblica dell'utente  legando ad essa una stringa che identifica l'utente stesso, creando quindi un certificato. Gli utenti ottengono le chiavi pubbliche autentiche scambiandosi i certificati oppure estraendoli da una directory pubblica.                           

Infine abbiamo il modello che usa sistemi che implicitamente garantiscono l’autenticità di parametri pubblici. In tali sistemi, che includono i sistemi basati sull’identità e quelli che usano chiavi certificate implicitamente, attraverso progetti algoritmici, la  modifica di parametri pubblici conduce a tecniche crittografiche non compromissibili da fallimenti [3].

 

3.1 Alberi di autenticazione

Gli alberi di autenticazione  forniscono un metodo per rendere disponibili dati pubblici la cui autenticità è verificabile, usando una struttura ad albero e una funzione hash adatta, con valore della radice autenticante. Le possibili applicazioni  includono: autenticazione di chiavi pubbliche, servizio di timestamping fidato ed autenticazione di parametri di validazione dell'utente.                             

Nell' autenticazione di chiavi  pubbliche (alternativa ai certificati di chiave pubblica), un albero di autenticazione creato da una terza parte fidata, che contiene le chiavi pubbliche degli utenti,  permette l’autenticazione di un grande numero di chiavi. Invece nel servizio di timestamping fidato, una terza parte fidata crea un albero di autenticazione, in modo da facilitarne il servizio. Nell'autenticazione di parametri di validazione dell’utente, un singolo utente crea  un albero che gli permette di pubblicare, con autenticità verificabile un grande numero di suoi parametri pubblici di validazione, come richiesto negli schemi di firma one-time [3].

    

3.1.1    Costruzione e uso degli alberi di autenticazione

Consideriamo un albero binario T con t foglie. Sia  h una funzione hash resistente alle collisioni. T può essere usato per autenticare t valori pubblici, Y1, Y2, … , Yt, costruendo un albero di autenticazione T* come segue :    

  1.   Etichetta  ognuna delle t foglie con un unico valore pubblico Yi.  

  2.   Etichetta l’arco diretto uscente dalla foglia etichettata Yi con h(Yi)

  3. Se l’arco sinistro e destro di un nodo interno sono etichettati h1 e h2, rispettivamente, etichetta l’arco uscente dal nodo con h(h1|| h2).

  4. Se gli archi  diretti  verso il nodo radice sono etichettati u1 e u2, etichetta la radice con h(u1|| u2).

                    

                      

                                                Figura 2. Un albero di autenticazione

 

Una volta che i valori pubblici sono assegnati alle foglie dell’albero binario, l’etichettatura di tutti i nodi è ben definita. La Figura 2 illustra un tale albero con quattro foglie. Assumendo che vi sia qualche mezzo per autenticare l'etichetta della radice, un albero di autenticazione fornisce un metodo per autenticare ognuno dei t valori pubblici Yi  delle foglie, come segue: per ogni valore pubblico,  Yi , c'è un'unica path (path di autenticazione) da Yi  alla radice. Ogni arco della path è un arco sinistro o destro di un nodo interno o della radice. Se e è un tale arco diretto verso il nodo x, memorizza l'etichetta sull'altro arco diretto verso x. Questa sequenza di etichette, (valori della path di autenticazione) usata nell'ordine corretto  fornisce l'autenticazione di Yi  , come illustrato nella Figura 2. Nota che se un singolo valore foglia è alterato, intenzionalmente o altrimenti, l'autenticazione del valore fallirà.  

Un esempio di verifica della chiave usando alberi di autenticazione è il seguente: riferendoci alla Figura 2  si osserva che il valore pubblico Y1  può essere autenticato fornendo la sequenza di etichette h(Y2), h(Y3), h(Y4). L'autenticazione procede come segue: computa h(Y1), poi computa h1=h(h(Y1)||h(Y2)), poi computa  h2=h(h1||h(Y3)), infine, accetta Y1  come autentico se h(h2||h(Y4)) = R, dove il valore della radice R è conosciuto come autentico.

Il vantaggio degli alberi di autenticazione è evidente considerando la memoria richiesta per permettere l’autenticazione di t valori pubblici usando il seguente approccio alternativo: un utente A autentica t valori pubblici Y1, Y2, … , Yt, registrando ognuno con una terza parte fidata. Questo approccio richiede la registrazione di t valori pubblici, quindi il tempo necessario aumenta al crescere di t. Invece, un albero di autenticazione  richiede solo la registrazione di un singolo valore con la terza parte (la radice). Se una chiave pubblica Yi di un utente A è il valore corrispondente ad una foglia nell’albero di autenticazione, e A desidera fornire informazioni a B permettendogli di verificare autenticità di Yi , allora A deve fornire a B sia Yi che i valori hash associati con la path di autenticazione da Yi alla radice; in più B deve avere conoscenza e fiducia nella autenticità del valore della radice R. Questi valori collettivamente garantiscono l’autenticità,  analogamente alla firma su certificati a chiave pubblica. Il  numero di valori che ogni parte  deve memorizzare (e fornire agli altri utenti per permettere la verifica della sua chiave pubblica) è pari all'altezza dell'albero [3].

 

 

  3.2 Certificati di chiavi pubbliche  

I certificati di chiavi pubbliche sono un veicolo attraverso il quale le chiavi pubbliche possono essere memorizzate, distribuite o spedite su un mezzo non sicuro senza pericolo di manipolazioni non individuate. L’obiettivo è di rendere disponibile la chiave pubblica di un utente agli altri, in modo tale che la sua autenticità e validità siano verificabili. I certificati sono documenti pubblici che attestano il legame di una chiave pubblica con un utente ed in alcuni casi, può essere necessario creare una catena di certificati tale che ognuno certifica la precedente, finché le parti coinvolte confidano nell’identità in questione.  

Più precisamente, si definisce un certificato di una chiave pubblica una struttura dati che consiste di una sezione dati e una sezione firma [3]. La sezione dati contiene testo in chiaro che include, almeno, una chiave pubblica ed una stringa che identifica la parte ad essa associata. La  sezione firma  consiste in una  firma digitale dell’autorità di certificazione sulla sezione dati, legando l’identità dell’utente alla chiave pubblica specificata. La forma più semplice di un certificato contiene la chiave pubblica ed il nome dell’utente, ma comunemente, contiene anche  data di scadenza, nome dell’autorità di certificazione che ha emesso il certificato, numero seriale ed altre informazioni. Ma la più importante è la firma digitale. Il formato più ampiamente accettato è definito dallo standard internazionale ITU-T X.509, la discussione sarà fornita in seguito (Standard dei certificati ) I certificati sono tipicamente usati per generare confidenza nella legittimazione della chiave pubblica. Essi sono firme digitali   la cui verifica può includere test di validità del certificato, eseguiti con più o meno rigore in base al contesto. L’uso più sicuro di autenticazione coinvolge l’associazione di uno o più certificati con ogni messaggio firmato. Il ricevente del messaggio vorrebbe verificare il certificato usando la chiave pubblica dell’autorità, e una volta trovata la chiave pubblica del mittente, verificare la firma del messaggio. Potrebbero esserci due o più certificati inclusi nel messaggio, i quali formano una catena gerarchica di certificati, dove un certificato testa l’autenticità del precedente. Alla fine della gerarchia di certificati  c’è l’autorità di certificazione top-level, la quale è fidata senza bisogno di certificati. Quindi la chiave pubblica dell’autorità top-level  deve essere conosciuta pubblicamente. E’ interessante notare che ci sono approcci alternativi di modelli di fiducia che evitano questa gerarchia.

Più è familiare il mittente al ricevente, più fiducia c’è nel fatto che la chiave pubblica è realmente quella del mittente e quindi meno bisogno c’è di verificare i certificati. Se Alice spedisce un messaggio a Bob ogni giorno, Alice può allegare una catena di certificati il primo giorno, che Bob verifica. Bob perciò memorizza la chiave pubblica di Alice  e non sono più necessari certificati o certificazione di certificati.  

Una buona regola è di includere quanto basta di una catena di certificati affinché l’emittente del certificato di più alto livello nella catena è ben conosciuto al ricevente. Se ci sono multipli riceventi, allora dovrebbero essere inclusi abbastanza certificati da coprire il bisogno di ogni ricevente [3].

   

3.3  Autorità di certificazione

I certificati sono emessi da un’autorità di certificazione (CA), che potrebbe essere una qualsiasi amministrazione centrale fidata, che garantisce per l’identità di coloro per cui emette i certificati e a cui associa una data chiave. La CA, infatti, è una terza parte fidata la cui firma sul certificato garantisce l’autenticità della chiave pubblica legata all’utente. Nel certificato, la stringa che identifica l’utente deve essere un unico nome nel sistema (nome distinto) che la CA tipicamente associa con l’entità real-world (identità reale dell’utente). Per esempio una compagnia potrebbe emettere certificati ai suoi dipendenti, o un’università ai suoi studenti, o una città ai suoi cittadini. Per prevenire la perdita di certificati, la chiave pubblica della CA deve essere attendibile, visto che essa permette ad ogni utente nel sistema, attraverso l’acquisizione e la verifica dei certificati, di trasferire la fiducia nella autenticità della chiave pubblica in ogni certificato firmato dalla CA. Quindi una CA deve pubblicizzare la sua chiave pubblica ed esibire un certificato di un’altra CA a più alto livello che attesti la validità della propria chiave pubblica, servendosi, quindi del trasferimento di fiducia.

Esempi di informazioni addizionali che la parte dati del certificato potrebbe contenere sono:

   

 

3.4 Creazione dei certificati di chiavi pubbliche

Prima di creare un certificato a chiave pubblica per un utente A, la CA potrebbe prendere appropriate misure (relative al livello di sicurezza richiesto), tipicamente in natura non crittografica, per verificare l’identità di A ed il fatto che la chiave pubblica da essere certificata è attualmente quella di A. Si possono distinguere due casi : il primo è quello in cui la parte fidata crea la coppia di chiavi pubbliche, e l'assegna ad uno specifico utente, includendo la chiave pubblica e l’identità dell’utente nel certificato. L’utente ottiene una copia della propria chiave privata su un canale sicuro (autentico e privato) dopo aver fornito la sua identità (per esempio mostrando un passaporto o una foto di persona).Tutte le parti, sottostanti, usando questo certificato essenzialmente delegano la fiducia a questa prima verifica di identificazione alla parte fidata.  

Nel secondo caso è l'utente che crea la sua coppia di chiavi, e trasferisce in modo sicuro la chiave pubblica alla parte fidata, preservando l’autenticità (per esempio su un canale fidato o di persona). Dopo la verifica dell’autenticità della chiave pubblica, la parte fidata crea il certificato a chiave pubblica come sopra. In quest’ultimo caso la CA potrebbe richiedere all’utente la dimostrazione della conoscenza della corrispondente chiave privata, per precludere ad un utente non legittimo di ottenere, per scopi maliziosi un certificato a chiave pubblica che lega il suo nome alla chiave pubblica di un altro utente.

Vediamo un semplice esempio del secondo caso : Alice genera la sua coppia di chiavi e spedisce la chiave pubblica ad un appropriato CA con la dimostrazione della sua identità. Il CA testa l’identità e fa ogni passo necessario per assicurarsi che la richiesta realmente proviene da Alice e che la chiave pubblica non è stata modificata durante il tragitto. Dopo spedisce un certificato che attesta il legame tra Alice e la sua chiave pubblica, con una gerarchia di certificati che verifica la chiave pubblica della CA. Alice può presentare questa catena di certificati ogni volta che lo desidera per dimostrare  la legittimità  della sua chiave pubblica [3].

Il processo totale attraverso il quale un utente B usa un certificato di una chiave pubblica per ottenere la chiave pubblica autentica di un altro utente A potrebbe essere riassunto nei seguenti passi :

  1.      (one-time) acquisire la chiave pubblica autentica della CA;

  2.      ottenere una stringa che identifica unicamente A;

  3.        acquisire su di un canale non sicuro (da un database centrale pubblico di certificati, o direttamente da A), un certificato della chiave pubblica corrispondente ad A ed accordarsi con la precedente stringa identificativa.

  4.       confronta la corrente data con il periodo di validità del certificato, basandosi su di  un clock locale fidato; verifica la corrente validità della chiave pubblica della CA; verifica la firma sul certificato di A usando la chiave pubblica di CA; verifica che il   certificato non è stato revocato;   

  5.       se tutti i test hanno successo accetta la chiave pubblica nel certificato come chiave  pubblica di A.

 

 

3.5 Certificati di attributo

I certificati di chiavi pubbliche legano una chiave pubblica e un identificativo, includono campi di dati addizionali necessari per chiarire questi legami, ma non sono usati per certificare informazioni addizionali. I certificati di attributi sono simili ai certificati di chiavi pubbliche, ma permettono la specifica di attributi (informazioni legate ad un CA, utente o alle chiavi pubbliche) oltre che le chiavi pubbliche. I certificati di attributi possono essere associati ad una specifica chiave pubblica, legando gli attributi alla chiave, con un metodo attraverso il quale la chiave è identificata, per esempio, attraverso il numero seriale del corrispondente certificato a chiave pubblica, o con il valore hash della chiave pubblica o del certificato. I certificati di attributi possono essere firmati da un’autorità di certificazione di attributi, creata insieme ad un’autorità di registrazione degli attributi, e distribuiti in una directory pubblica. Più generalmente ogni utente con una chiave firmata ed un’appropriata autorità di riconoscimento potrebbe creare un certificato di attributi [3].  

 

 

3.6 Sistemi basati sull’identità

I sistemi basati sull’identità somigliano ai sistemi a chiave pubblica ordinari, coinvolgendo una trasformazione privata ed una pubblica, ma gli utenti non hanno un’esplicita chiave pubblica. La chiave pubblica è effettivamente rimpiazzata (o costruita) da informazioni pubblicamente disponibili  sull’identità dell’utente (nome e indirizzo o indirizzo rete). Ogni informazione pubblicamente disponibile che identifica un utente e può essere inequivocabilmente associata con l’utente, può servire come informazione di identità [3].

Un sistema crittografico basato sull’identità (sistema ID-based) è un sistema asimmetrico in cui l’informazione di identificazione pubblica di un utente gioca il ruolo di chiave pubblica, ed è usata come input ad una autorità fidata T, per computare la chiave privata corrispondente all’utente. Dopo averla computata, T trasferisce la chiave privata all’utente su di un canale sicuro (autentico e privato). Questa chiave privata è computata non solo dalle informazioni di identità dell’utente, ma deve essere anche funzione di informazioni privilegiate conosciute solo da T (chiave privata di T). Questo è necessario per prevenire falsificazioni – è essenziale che solo T sia capace di creare chiavi private valide corrispondenti ad una data informazione di identificazione.

In alcuni casi dati pubblici addizionali DA definiti dal sistema devono essere associati ad ogni utente A in aggiunta all’identità IDA; tali sistemi non sono più sistemi basati puramente sull’identità dato che né l’autenticità di DA, nè IDA devono essere esplicitamente verificati.

I sistemi basati sull’identità differiscono dai sistemi basati sulla chiave pubblica nel fatto che l’autenticità dei dati pubblici di un utente specifico non sono esplicitamente verificati, mentre la verifica delle chiavi pubbliche è necessaria nei sistemi basati sui certificati. La ridondanza dei dati pubblici in sistemi ID-based insieme all’uso di dati autentici pubblici di sistema, protegge implicitamente dalle falsificazioni; se sono usati dati pubblici non corretti la trasformazione fallisce. Più precisamente la verifica della firma e l’autenticazione dell’identità falliscono, la cifratura della chiave pubblica diventa testo indecifrabile e l’accordo sulle chiavi stabilisce differenti chiavi tra le parti.

Lo scopo dei sistemi ID-based è di creare un sistema crittografico modellante un sistema ideale di posta in cui la sola conoscenza del nome dell’utente è sufficiente a permettere che la posta sia spedita e letta solo da quella persona e la verifica delle firme che solo quella persona può aver prodotto. In un tale sistema crittografico ideale, gli utenti non hanno bisogno di scambiarsi nè chiavi simmetriche nè chiavi pubbliche, le  directory pubbliche (files di chiavi pubbliche o certificati) non sono necessarie, ed   i servizi di un’autorità fidata sono necessari solamente durante la fase di setup (durante la quale gli utenti acquisiscono parametri pubblici autentici di sistema).

 

 

3.7  Chiavi pubbliche implicitamente certificate

Un’altra variante dei sistemi a chiave pubblica sono i sistemi asimmetrici con chiavi pubbliche implicitamente certificate. Qui chiavi pubbliche esplicite degli utenti esistono, ma devono essere ricostruite piuttosto che trasportate da certificati a chiave pubblica come per i sistemi basati sui certificati. I sistemi implicitamente certificati sono progettati nel seguente modo:  le chiavi  pubbliche degli utenti possono essere ricostruite (da altri utenti) da dati pubblici (i quali sostituiscono un certificato) i quali  includono: dati pubblici associati  con una parte fidata T, l’identità dell’utente (nome ed indirizzo) e dati addizionali pubblici dell'utente.

Infine l’integrità di una chiave pubblica ricostruita non è direttamente verificabile ma una chiave pubblica corretta può essere ricostruita solo dai dati pubblici autentici di un utente.

Per quanto riguarda le chiavi pubbliche ricostruite il sistema deve garantire due aspetti:

Esistono due classi di chiavi pubbliche implicitamente certificate. La prima è quella delle chiavi pubbliche basate  sull’identità, dove la chiave privata di ogni utente A è calcolata da una parte fidata T, usando informazioni di identificazione di A e la chiave privata di T; essa è anche funzione dei dati pubblici di ricostruzione dell’utente specifico A che sono stabiliti a priori da T. La seconda è quella delle chiavi pubbliche auto-certificate, in cui ogni utenteA calcola la sua chiave privata e la corrispondente chiave pubblica. I dati pubblici di ricostruzione sono computati da T come funzione della chiave pubblica e delle informazioni di identificazione di A (inviate da A a T) e della chiave privata di T. La prima classe richiede molta più fiducia nella terza parte, infatti questa ha accesso alle chiavi private degli utenti a differenza della seconda classe [3].

   

3.8 Confronto tra tecniche di distribuzione di chiavi pubbliche      

Le  tecniche di distribuzione di chiavi pubbliche differiscono nella struttura e nella gestione delle chiavi stesse, infatti, i sistemi a chiave pubblica basati sui certificati hanno chiavi pubbliche esplicite, mentre i sistemi ID-based no, e nei sistemi implicitamente certificati le chiavi pubbliche sono ricostruite. Le chiavi pubbliche esplicite dei sistemi a chiave pubblica sono sostituite dalla tripla (DA, IDA, PT) per sistemi basati sull’identità (dove IDA è la stringa di identificazione di A, DA sono dati pubblici addizionali definiti da T e relazionati alla chiave privata di A e a IDA, e PT è la chiave pubblica dell’autorità T); e dalla tripla (RA, IDA, PT)  per sistemi con chiavi pubbliche implicitamente certificate. In questo caso, un’esplicita chiave pubblica PA è ricostruita da questi parametri. La ricostruzione dei dati pubblici RA gioca un ruolo analogo ai dati pubblici DA. L’autenticità delle  chiavi pubbliche può (e deve) essere esplicitamente verificata nei sistemi basati sui certificati, ma non è necessario farlo nei sistemi ID-based e quelli implicitamente certificati.

L’autorità fidata non ha bisogno di conoscere le chiavi private degli utenti nei sistemi a chiave pubblica basati sui certificati o in quelli implicitamente certificati con le chiavi pubbliche auto-certificate; ma ne ha bisogno nei sistemi ID-based e in quelli implicitamente certificati con chiavi ID-based. Analogamente ai sistemi basati sull’identità, le chiavi pubbliche implicitamente certificate dipendono da informazioni che identificano l’utente, e in questo senso sono anche “basate sull’identità”. Comunque i sistemi ID-based evitano esplicite chiavi pubbliche, mentre chiavi pubbliche implicitamente certificate non sono ristrette all’identità degli utenti e potrebbero essere esplicitamente computate.

Le due classi di chiavi pubbliche implicitamente certificate differiscono tra loro nella ricostruzione dei dati pubblici e delle chiavi private degli utenti come segue:

In tutti e tre gli approcci, ad una terza parte, che è fidata ad un certo livello, è richiesto di fornire un link di trasferimento sicuro tra gli utenti che potrebbero non aver mai incontrato gli altri e mai condiviso niente oltre che i parametri autentici del sistema. I vantaggi di  certificati impliciti di chiavi pubbliche  rispetto ai certificati a chiave pubblica sono: la possibilità di ridurre lo spazio delle richieste (i certificati firmati richiedono spazio per le firme); la possibilità di salvare la computazione (la verifica della firma, come richiesto per i certificati, è evitata); la possibilità di salvare le comunicazioni (se l’identità è conosciuta a priori). Contando su questi punti, la computazione  è attualmente richiesta per la ricostruzione della  della chiave pubblica; un’addizionale ricostruzione di dati pubblici è tipicamente  richiesta.  

La revoca delle chiavi pubbliche può essere indirizzata in schemi ID-based e in sistemi che usano chiavi pubbliche implicitamente certificate, incorporando informazioni tali come periodo di validità della chiave o numero seriale in una stringa di identificazione usata per computare la chiave pubblica dell’utente. Il mandato di revoca è quindi analogo a quello dei certificati a chiave pubblica discusso in seguito. Le informazioni addizionali pertinenti l’uso di una chiave o una politiche di sicurezza associate possono essere similmente incorporate [3].