PUBLIC KEY CERTIFICATE

Per verificare una firma digitale è necessario conoscere la chiave pubblica del firmatario ed essere sicuri che quest'ultima corrisponda effettivamente alla chiave privata del firmatario stesso e che l'identità di chi firma sia già stata verificata rigorosamente. Da questo deriva il bisogno di far riferimento a una terza parte fidata, la cui principale funzione è quella di certificare il legame tra un utente e la sua chiave pubblica. Tale legame è contenuto in una struttura dati conosciuta come Public Key Certificate (PKC).

Certification Authority

La terza parte fidata che, ricevute un insieme di informazioni, le verifica e rilascia al richiedente un certificato di chiave pubblica, è detta Certification Authority (CA). Il certificato rilasciato reca la firma digitale della CA, la cui affidabilità è riconosciuta da tutti gli utenti. Le CA sono di solito grandi istituzioni a livello nazionale o spesso internazionale legalmente autorizzate ad emettere certificati di identità. Le CA possono avere più CA subordinate di cui si fidano e a cui delegano i poteri di autenticazione e certificazione.

Revoca di PKC e Certificate Revocation List

In caso di compromissione rilevata o semplicemente sospettata della chiave privata corrispondente alla chiave pubblica contenuta nel PKC, o di cambiamento di una qualsiasi delle informazioni contenute in quest’ultimo, la CA revoca il PKC e lo inserisce in una Certificate Revocation List (CRL). Una CRL, quindi, non è altro che una lista di certificati che sono stati revocati prima della loro scadenza naturale. Sarà cura della CA mantenere aggiornata la CRL.

Registration Authority

L’emissione effettiva di un PKC da parte di una CA deve essere preceduta da una fase di registrazione dell’utente che richiede il certificato. L’entità che si occupa di questa fase è la Registration Authority (RA). Una RA è un’entità separata dalla CA, non firma né i certificati né le CRL, ma ha la responsabilità di registrare e verificare alcune o tutte le informazioni (in particolare l’identità del titolare) necessarie alla CA per emettere i certificati e le CRL e per effettuare altre operazioni di gestione dei certificati.

Public Key Infrastructure

Per usare i certificati di chiave pubblica c’è bisogno di un’infrastruttura chiamata Public Key Infrastructure (PKI). Una PKI non è altro che l’insieme di hardware, software, persone, politiche e procedure necessarie per creare, gestire, memorizzare, distribuire e revocare PKC basati sulla crittografia a chiave pubblica. Oltre alle componenti fondamentali (CA e RA), un’infrastruttura per le chiavi pubbliche comprende anche un sistema distribuito di directory (contiene i PKC e le CRL reperibili dagli utenti quando necessario), un database gestito esclusivamente dalla CA (contiene un backup delle chiavi, comprese quelle scadute, che, a differenza della directory, è privato ed accessibile solo dalla CA), un generatore di chiavi (crea coppie di chiavi pubbliche e/o private) ed un name server (responsabile del trattamento dello spazio dei nomi).

Processo identificativo

Normalmente, quando un utente invia un messaggio firmato, allega il proprio certificato di chiave pubblica, in modo tale che il destinatario non ha bisogno di interrogare la directory delle CA tranne che per assicurarsi che il certificato non sia stato revocato o sospeso. Più precisamente, quando un destinatario riceve una busta crittografica contenente il documento digitale, la firma digitale e il PKC del mittente, tutto quello che deve fare è: assicurarsi che il PKC del mittente sia stato emesso da una CA fidata, estrarne la chiave pubblica e utilizzare quest'ultima per verificare la firma digitale allegata al documento ricevuto. Tutta questa procedura è nota come processo di identificazione del mittente ed è mostrata nella figura successiva.

Processo autorizzativo tradizionale

Nella maggior parte dei casi, però, quando un destinatario riceve un documento digitale, non basta verificare la firma digitale del mittente per considerare valido a tutti gli effetti il documento stesso. In molti casi, infatti, è più importante stabilire con sicurezza quali siano gli "ATTRIBUTI" del firmatario, cioè quali siano i privilegi, le funzioni e i ruoli ricoperti da quest'ultimo. Quindi, al processo di identificazione del mittente, deve sempre seguire un processo di autorizzazione.

Esistono numerosi esempi di casi in cui non è sufficiente sapere chi ha firmato un documento, ma è importante essere certi che egli era autorizzato a farlo. Ad esempio, un progetto per l'edificazione di un palazzo deve necessariamente essere firmato da un ingegnere, oppure, in una grande azienda, l'emissione di ordini d'acquisto per importi elevati può essere firmata solo da chi ricopre un ruolo particolare, ad esempio il direttore generale.

Il processo autorizzativo tradizionale si basa sul vecchio concetto di “anagrafica utenti”, cioè un database locale in cui sono memorizzate informazioni di vario genere sugli utenti e che viene consultato a livello applicativo, a valle del processo identificativo. Tuttavia, le informazioni in esso contenute possono essere facilmente modificate, cosicché diventa difficile stabilire quali fossero gli attributi di un determinato utente al momento della firma. Questo problema si presenta quando i documenti firmati digitalmente non vengono esaminati immediatamente dal destinatario alla loro ricezione, ma magari dopo diverse settimane o mesi, quando gli attributi del mittente-firmatario possono anche essere cambiati. Quindi la soluzione tradizionale del database non è molto efficace e di fatto si usa solo all’interno di comunità chiuse di utenti. Il processo autorizzativo tradizionale è schematizzato nella figura successiva.