.. meta:: :language: it :description language=it: Firma digitale e protocolli di autenticazione :description language=en: Digital signature and authentication protocols :keywords: IT Security, digital signature, authentication protocol :author: Luciano De Falco Alfano 07 Firma digitale e protocolli di autenticazione =================================================== .. contents:: :local: [*lezione del 2019-10-31*] Firma digitale ----------------- L'autenticazione del messaggio non protegge mittente e ricevente l'uno nei confronti dell'altro. Si consideri che, se *A* e *B* condividono una chiave, si può avere: * *A* produce un messaggio, e successivamente dichiarare che lo ha prodotto *B*; * per il punto precedente, *A* può negare di avere inviato un messaggio a *B*. Se non vi è completa fiducia tra mittente e destinatario, è necessario ricorrere alla **firma digitale** (**igital signature**). **Requisiti della firma digitale**. Sono i seguenti: * è un gruppo di bit il cui valore dipende dal messaggio che deve essere firmato; * usa delle informazioni univoche del mittente, per prevenire forgery e source repudiation; * facile da produrre; * relativamente semplice da riconoscere e verificare, * computazionalmente improponibile creare una firma digitale per un attaccante; * deve essere possibile immagazzinarne una copia. Firma digitale diretta -------------------------- La **firma digitale diretta** (**direct digital signature**) coinvelge solo i partecipanti alla comunicazione: * l'intero messaggio può essere cifrato con la chiave privata del mittente (si veda l'autenticazione dei messaggi); * un codice hash del messaggio può essere cifrato con la chiave privata del mittente (vedi autenticazione del messaggio). La debolezza di tutte le firme digitali descritte consiste nel fatto che lo schema si basa sulla correttezza di mittente e destinatario * il mittente può negare la paternità del messaggio; * o può produrre un messaggio con data ed ora ad hoc. Firma digitale arbitrata --------------------------- I problemi della firma digitale diretta possono essere indirizzati usando un arbitro. Ogni messaggio firmato dal mittente *X* al destinatario *Y* deve prima passare Per un arbitro *A*. Il compito dell'arbitro consiste nel sottoporre il messaggio e la relativa firma ad una serie di controlli per verificare origine e contenuti. Qui di seguito tre esempi di protocolli che possono essere usati nel caso di firma digitale con arbitro. .. image:: ./images/15_arbitred_signature.svg Lo schema *(a)* permette la libera lettura del messaggio *M* che è trasmesso in chiaro da *X* verso l'arbitro *A*. Questo schema, e il successivo *(b)*, utilizzano chiavi di sessione simmetriche. Lo schema *(b)*, cifra il messaggio impedendone la lettura senza restrizion. D'altro canto l'uso di chiavi simmetriche non impedisce la possibilità di negare il messaggio se *A* collude con *X* , né le contraffazione del messaggio se *A* collude con *Y*. Nello schema *(c)* l'uso di chiavi asimmetriche pubbliche/private permette la confidenzialità, impedisce la contraffazione e nega la ricusazione dell'invio. Inoltre la collusione dell'arbitro non è possibile. Mutua autenticazione ------------------------ I protocolli di mutua autenticazione abilitano le parti in comunicazione a stabilire l'uno l'identità dell'altra parte e a scambiarsi chiavi di sessione. Vi sono due principali problemi: * la *confidenzialità* nello scambio delle chiavi previene l'uso di identità contraffatte (*masquerade*) e la compromissione di *session key*; * la *tempestività* è importante per contrastare il pericolo del reinvio di messaggi validi precedentemente (*replay*). I metodi per contrastare i *reply attack* sono: * **numeri di sequenza** - (*sequence number*) ogni messaggio usato in uno scambio per autenticazione è numerato. I numeri non sono riutilizzati e ogni partecipante alla conversazione deve ricordare l'ultimo numero gestito per ogni controparte; * **timestamps** - i messaggi contengono un *timestamp* che, a giudizio del ricevente, è abbastanza vicino all'ora corrente; ciò richiede una qualche forma di sincronizzazione degli orologi; * **challange/response** - (*sfida/risposta*) il partecipante *A*, in attesa di un nuovo messaggio da *B*, gli invia un *nonce* (questa è la sfida); il successivo messaggio da *B* deve contenere a sua volta un *nonce* (la risposta) calcolato correttamente in funzione della sfida. **Approcci con cifra simmetrica**. Ogni partecipante condivide una *master key* con un *Key Distribution Center* (*KDC*). Il *KDC* è responsabile: * della *generazione* della *session key*, * e della sua *distribuzione*. Questi concetti sono importanti per capire i meccanismi di autenticazione del Kerberos. Il protocollo è come segue. .. image:: ./images/16_mutual_authentication_se.svg Nel diagramma temporale precedente vediamo: * al passo *2.* il processo *A* acquisisce in modo sicuro la chiave di sessione :math:`K_S`; * mentre in *3.* è *B* cha acquisisce la chiave predetta; * al passo *4.* il processo *B* dimostra ad *A* di conoscerlo, * mentre al passo *5.* è il processo *A* a confermare la propria identità a processo *B*. In questo protocollo non si può escludere il riutilizzo di vecchie chiavi, eventualmente compromesse. Per evitare questo aspetto si può aggiungere un *timestamp*, come indicato nel seguente diagramma temporale. .. image:: ./images/17_mutual_authentication_se_2.svg La presenza dei *timestamp* al punto *2.* assicura che la secret key :math:`K_S` è stata appena generata. Mentre i punti *4.* e *5.* come al solito assicurano che *A* sia l'interlocutore reale. D'altro canto, l'uso di *timestamp* richiede che gli orologi di diversi partecipanti alla conversazione siano sincronizzati. In particolare non è accettabile che l'orologio di *B* sia sensibilmente in anticipo rispetto quello di *A*. Un ulteriore protocollo, sicuro ma senza necessità di sincronizzazione stretta degli orologi, è il seguente: .. image:: ./images/18_mutual_authentication_se_3.svg In questo caso in *1.* *A* usa il *nonce* :math:`N_a`, che riavrà con la chiave di sessione :math:`K_S`, ottenendo la sicurezza che la chiave il questione è stata generata specificamente per la sua richiesta. Lo step *2.* è la richiesta criptata di *B* verso KDC di inviare la session key :math:`K_S` ad *A*. Include un *timeout* :math:`T_b` entro cui la session key non è più utilizzabile. La fase *3.* vede KDC inviare ad *A* le credenziali e la session key. La presenza di :math:`E_{K_b}[ID_{A}||K_{S}||T_{b}]` serve ad *A* per effettuare le autenticazioni. Mentre in :math:`E_{K_{a}}[ID_{B}||N_{A}||K_{S}||T_{b}]` la presenza di :math:`N_{a}` assicura che non si tratta di un *replay*. Inoltre fornisce la session key :math:`K_{S}` e il tempo limite per l'utilizza, indicato da :math:`T_{b}`. Infine in *4.* il ticket :math:`E_{K_b}[ID_{A}||K_{S}||T_{b}]` fornisce a *B* la session key, da usare anche per decrittare la coda del messaggio, in cui :math:`N_{b}` indica che non si tratta di un *replay*. Kerberos --------------- **Kerberos** è un sistema di autenticazione utilizzabile in contesti in cui una serie di utenti, da workstation diverse, desiderano accedere a servizi forniti da macchine server. I server devono essere in grado di: * limitare l'accesso agli utenti autorizzati; * autenticare le richieste per il servizio. *Kerberos* è un servizio di autenticazione sviluppato nell'ambito del Progetto Athena, al MIT. In esso: * un utente prova la propria identità per ogni servizio richiesto; * inoltre i server provano la propria identità ai client. La versione attuale è la 4. *Kerberos 4* è complesso. È difficile capire la necessità di tutti gli elementi che contiene. Seguendo Bill Bryant, del Progetto Athena, analizziamo diversi esempi di dialogo client/server; ricordando che il server di autenticazione (AS): * memorizza le user passwords; * condivide una *secret key* univoca con ogni server. Un primo esempio è il seguente: .. image:: ./images/19_kerberos4_1.svg In questo caso osserviamo che che la password, in chiaro, viene inserita più volte. Inoltre il ticket potrebbe essere utilizzato più volte, verso gli stessi servizi, o verso servizi diversi. Comunque il problema più grave è che un *eavesdropper* può intercettare la password. Per risolvere questo problema passiamo al seguente esempio, in cui introduciamo un nuovo server: il ticket-granting server (TGS): .. image:: ./images/20_kerberos4_2.svg Qui però sorge il problema che il TGS può essere sottoposto ad attacchi di tipo *reply*. Può ricevere :math:`ticket_{TGS}` con :math:`lifetime_1` valida da un eventuale attaccante. Si pone quindi il problema di autenticare il servizio. Arriviamo così allo schema reale del *Kerberos 4*, che è composto dai seguenti servizi di autenticazione: +-------------------------------------------------------------------------------------------------------------------------------------+ | (a) Authentication Service Exchange: to obtain ticket-granting ticket | +=====================================================================================================================================+ | | |.. math:: | | \begin{equation} | | (1) \mathbf{C} \rightarrow \mathbf{AS}: ID_{c} || ID_{tgs} || TS_{1} | | \end{equation} | | | |.. math:: | | \begin{align} | | (2) \mathbf{AS} \rightarrow \mathbf{C}: &E_{K_{c}}[K_{c,tgs}||ID_{tgs}||TS_{2}||Lifetime_{2}||Ticket_{tgs}] \\ | | &Ticket_{tgs} = E_{K_{tgs}}[K_{c,tgs}||ID_{C}||AD_{C}||ID_{tgs}||TS_{2}||Lifetime_{2}] | | \end{align} | | | +-------------------------------------------------------------------------------------------------------------------------------------+ . +-------------------------------------------------------------------------------------------------------------------------------------+ | (b) Ticket-Granting Service Exchange: to obtain service-granting ticket | +=====================================================================================================================================+ | | |.. math:: | | \begin{equation} | | (3) \mathbf{C} \rightarrow \mathbf{TGS}: ID_{v} || Ticket_{tgs} || Authenticator_{c} | | \end{equation} | | | |.. math:: | | \begin{align} | | (4) \mathbf{TGS} \rightarrow \mathbf{C}: &E_{K_{c,tgs}}[K_{c,v}||ID_{v}||TS_{4}||Ticket_{v}] \\ | | &Ticket_{tgs} = E_{K_{tgs}}[K_{c,tgs}||ID_{C}||AD_{C}||ID_{tgs}||TS_{2}||Lifetime_{2}] \\ | | &Ticket_{v} = E_{K_{v}}[C_{c,v}||ID_{C}||AD_{C}||ID_{v}||TS{4}||Lifetime_{4}] \\ | | &Authenticator_{c} = E_{K_{tgs}}[ID_{c}||AD_{C}||TS_{3}] | | \end{align} | | | +-------------------------------------------------------------------------------------------------------------------------------------+ . +-------------------------------------------------------------------------------------------------------------------------------------+ | (b) Client/Server Authentication Exchange: to obtain service | +=====================================================================================================================================+ | | |.. math:: | | \begin{equation} | | (5) \mathbf{C} \rightarrow \mathbf{V}: Ticket_{v} || Authenticator_{c} | | \end{equation} | | | |.. math:: | | \begin{align} | | (4) \mathbf{V} \rightarrow \mathbf{C}: &E_{K_{c,v}}[TS_{5} + 1] \text{(for mutual authentication)} \\ | | &Ticket_{v} = E_{K_{v}}[C_{c,v}||ID_{C}||AD_{C}||ID_{v}||TS{4}||Lifetime_{4}] \\ | | &Authenticator_{c} = E_{K_{c,v}}[ID_{c}||AD_{C}||TS_{5}] | | \end{align} | | | +-------------------------------------------------------------------------------------------------------------------------------------+ Quindi *Kerberos 4* ha due server: *l'authentication server* (AS) e il *Ticket-Granting server* (TGS). In generale il dialogo utente (Kerberos/server) si sviluppa come segue: 1. l'utente fa login sulla workstation e richiede un servizio su server * la workstation invia (una sola volta per la durata della sessione di lavoro dell'utente) una richiesta di ticket-granting ticket al AS; 2. l'AS verifica i diritti di accesso dell'utente in un DB, crea il ticket-granting ticket e la *session key*; i risultati sono cifrati usando una chiave derivata dalla password utente; * la AS invia ticket + session key alla workstation; 3. la workstation richiede la password all'utente e la usa per decifrare il messaggio ricevuto da AS; * la workstation invia al TGS il ticket e un autenticatore con: nome utente, network address e l'orario; * quindi, per ogni tipo di servizio richiesto, la workstation invia al TGS una richiesta di service-granting ticket; 4. il TGS decifra ticket e authenticator, verifica la richiesta, quindi crea il ticket per il server richiesto; * il TGS invia ticket + session key alla workstation; 5. la workstation invia ticket e authenticator al server * per ogni sessione di servizio la workstation invia la richiesta di servizio al server; 6. il server verifica che ticket e authenticator collimino; quindi garantisce l'accesso al servizio; * se è richiesta una mutua autenticazione, il server risponde alla workstation con un authenticator. **Kerberos Realms**. Un ambiente Kerberos consiste di: * un server Kerberos; * una serie di clients registrati sul server; * dei server applicativi, che condividono chiavi con il server. Quest'insieme di elementi è detto **realm**, che tipicamente è un singolo dominio amministrativo. Se esistono più *realm*, i loro server Kerberos condividono *secret keys* e sono trustati l'uno con l'altro. Servizio di autenticazione X.509 --------------------------------------- **X.509** è parte del servizio di directory standard CCITT X.500. Definisce una struttura per l'autenticazione di servizi: * le directory possono immagazzinare **certificati con chiave pubblica**; * ogni certificato contiene la chiave pubblica di un utente, firmata da una autorità di certificazione. Inoltre definisce i protocolli di autenticazione. Il formato dei certificati *X.509* è utilizzato in vari contesti. Ad esempio in *S/MIME*, *IP Security*, *SSL/TLS* e *SET*. Qui di seguito si riporta la loro struttura, e la struttura dati, al lista, per la loro revoca: .. image:: ./images/21_x509.svg Questi certificati, quando generati da una Certification Authority (CA) hanno le caratteristiche: * ogni utente con accesso alla chiave pubblica della CA può verificare la chiave pubblica che è stata certificata; * nessun attore diverso dalla CA può modificare il certificato senza che l'alterazione venga rilevata. Visto che i certificati non sono modificabili, possono essere immagazzinati in una directory senza ricorrere a misure di sicurezza speciali. È possibile avere più di una *Certification Authority*, e questo concetto conduce **all'uso gerarchico delle CA**. Ad esempio, si consideri la seguente relazione tra certificati ed autorità di certificazione (gerarchica, come suggerito da *X.509* per facilitare la navigazione): .. image:: ./images/22_more_cas.svg Dall'immagine notiamo che *A* e *B* sono certificati da autorità diverse; rispettivamente *X* e *Z*. Se *A* vuole controllare il certificato di *B* lo deve decrittare usando la chiave pubblica di *Z*. Quindi deve ottenere in modo sicuro la chiave pubblica di *Z*. Se le CA sono certificate l'una con l'altra, *A* può utilizzare una catena di certificati per arrivare ad ottenere la chiave pubblica di *Z*; ad esempio [#]_:: X<>W<>V<>Y<>Z<> Mentre *B* può utilizzare:: Z<>Y<>V<>W<>X<> Sia *A* che *B* dovranno avere nella loro directory dei certificati, tutti i certificati necessari per risolvere la catena di loro interesse. Procedure di autenticazione ------------------------------- **One-way authentication** .. image:: ./images/24_authentication_1.svg Questo protocollo stabilisce: 1. l'identità di *A* e che il messaggio è stato generato da *A*; 2. che il messaggio è destinato a *B*; 3. l'integrità e l'originalità [#]_ del messaggio. **Two-way authentication** .. image:: ./images/25_authentication_2.svg In questo case si hanno in più i seguenti aspetti: 4. l'identità di *B* e che il messaggio di risposta è stato generato da *B*; 5. che il messaggio è destinato ad *A*; 6. l'integrità e l'originalità della risposta. **Three-way authentication** .. image:: ./images/26_authentication_3.svg Infine abbiamo anche: 7. un messaggio finale da *A* a *B* che contiene la copia firmata del nonce :math:`r_B` Infrastruttura per chiavi pubbliche -------------------------------------- La RFC 2822 definisce una infrastruttura per chiavi pubbliche (Public-Key Infrastructure: PKI) come un insieme di hardware, software, persone, politiche e procedure necessarie per gestire certificati digitali. Il gruppo di lavoro IETF per la Public Key Infrastructure X.509 (PKIX) ha definito un modello formale basato su *X.509* in grado di implementare una architettura su Internet basata su certificati. Gli elementi dell'architettura sono: * entità finali; * Certification Authority (CA); * Registration Authority (RA); * emettitore di Certificate Revocation List (CRL); * repository dei certificati e delle CRL. Sono disponibili le seguenti funzioni di gestione: * registrazione; * inizializzazione; * certificazione; * recupero di coppie di chiavi; * aggiornamento di coppie di chiavi; * richiesta di revoca; * certificazione incrociata. Di seguito si riporta lo schema delle relazioni tra gli elementi del PKI: .. image:: ./images/23_pki.svg ------------------------------ .. [#] Come indicato in figura, Y<> significa che la Certification Authority *Y* certifica l'entità *Z*. .. [#] Originalità: non è stato inviato più volte.