La posta elettronica è lo strumento base delle comunicazioni digitali. Tuttavia per la struttura stessa della rete Internet i messaggi di posta elettronica viaggiano in chiaro e passano per diversi server prima di arrivare a destinazione, cosicché l’intercettazione delle e-mail è un compito piuttosto facile, e la lettura del contenuto non presenta nessuna difficoltà.

Inoltre il mittente del messaggio può essere facilmente contraffatto e il contenuto dell’e-mail può essere manomesso, oltre che osservato, consentendo così la creazione di e-mail contraffatte.

Per prevenire questi rischi, e dotare la posta elettronica di nuovi servizi, sono necessari servizi di: autenticazione del mittente, firma elettronica e autenticazione del messaggio, cifratura del messaggio, gestione di ricevute autenticate del messaggio (non-ripudio) e dell’orario di ricezione (time-stamping).

I due principali standard di posta elettronica sicura sono: PGP-Mail ed S/MIME.

E’ opportuno analizzare in dettaglio i due standard e confrontare le diverse proposte di PKI all’interno delle quali essi operano.

PGP è l’acronimo di Pretty Good Privacy, ed è un software sviluppato agli inizi degli anni Novanta per consentire lo scambio di posta elettronica sicura.

PGP si basa sugli algoritmi di crittografia a chiave pubblica RSA e a chiave segreta IDEA, e consente la cifratura e la firma digitale dei messaggi di posta elettronica.

Questo programma divenne ben presto lo “standard de facto” per l’utilizzo della posta elettronica sicura, grazie al fatto di essere semplice, innovativo, efficiente, e grazie ad una politica di commercializzazione molto efficace: esso venne diffuso via Internet, e commercializzato dapprima con una licenza shareware e poi con una licenza freeware.

Poiché PGP non riconosce l’esistenza di enti certificatori, ed è estraneo al concetto di certificati di chiave pubblica, esso fa uso di un diverso meccanismo di diffusione e validazione delle chiavi pubbliche.

Ogni utente, oltre ad avere una propria coppia di chiavi pubblica/privata, ha anche una lista di chiavi pubbliche di altri utenti, con cui intende scambiare posta sicura, che ritiene affidabili. Per evitare manomissioni, questa lista (detta keyring) è memorizzata e firmata con la propria chiave privata. In realtà più che firmare l’intera lista, l’utente aggiunge la propria firma a ciascuna delle chiavi pubbliche che ritiene affidabili.

PGP consente lo scambio tra utenti delle liste di chiavi pubbliche ritenute valide, ciascuna firmata con la propria chiave privata, e questo fornisce un meccanismo per valutare l’affidabilità della chiave pubblica di un utente sconosciuto in base alle firme apposte da altri utenti ritenuti affidabili.

Al momento dell’accettazione di una chiave pubblica come affidabile, e dunque dell’apposizione della propria firma a quella chiave, PGP consente di aggiungere una proprietà che caratterizza il livello di affidabilità che si attribuisce a quella chiave pubblica. I possibili valori sono:

Questo meccanismo di distribuzione delle chiavi pubbliche va sotto il nome di “Web of Trust”, ed è la forma di PKI che PGP si è dato.

La Web of Trust implementata da PGP elimina la necessità di enti certificatori; non c’è bisogno di attendere l’emissione di un certificato di chiave pubblica per iniziare a cifrare/firmare i messaggi. La struttura è decentralizzata ed i costi operativi, anche in termini di tempo, sono sicuramente più bassi rispetto al meccanismo di validazione di una public key infrastructure.

Tuttavia questo meccanismo è più rischioso perché non c’è un controllo diretto sulla validità della chiave in questione, ma anzi si fa affidamento su una catena di affermazioni di validità di cui non si ha il controllo diretto. Inoltre essa pone dei problemi tecnici nel caso in cui si debba essere revocare una chiave pubblica.

Con PGP dunque non si ha una garanzia totale circa l’affidabilità di una chiave pubblica, ma piuttosto un indice di affidabilità, tanto più alto quanto maggiore è il numero delle firme affidabili apposto a quella chiave.

La proposta di PGP-Mail non è mai stata ratificata come standard, questo ne ha impedito l’accettazione ufficiale da parte di molte organizzazioni, e ne ha limitato lo sviluppo. La sua popolarità sta rapidamente scemando a favore del nuovo standard S/MIME.

S/MIME si va affermando come lo standard definitivo per lo scambio di posta elettronica sicura; esso fa uso della crittografia a chiave pubblica, dei certificati X.509, e si inserisce perfettamente all’interno di una architettura PKI.

S/MIME è già ampiamente supportato da molte applicazioni, gode di un vasto supporto commerciale, e la sua diffusione è in continuo aumento.

Pur essendo uno standard “de facto”, ufficialmente S/MIME non è ancora stato dichiarato standard a tutti gli effetti; le sue specifiche sono state sottoposte agli organismi competenti sotto forma di RFC e allo stato attuale la proposta è sotto forma di Internet Draft.

Non c’è dubbio comunque che S/MIME verrà ratificato come standard in tempi molto brevi, e con modifiche minime rispetto alla sua forma attuale.

Poiché l’intera struttura di questa proposta è basata sulla architettura MIME è opportuno esaminare preliminarmente lo standard MIME.

L’acronimo MIME (Multipupose Internet Mail Estensions) indica un insieme di specifiche per la formattazione dei messaggi di posta elettronica universalmente accettato, il cui scopo è quello di consentire che i messaggi transitino, nel loro viaggio da mittente a destinatario, attraverso diversi sistemi di elaborazione senza subire danneggiamenti o perdite di dati.

La codifica MIME si preoccupa di modificare i dati da trasmettere per consentire la trasmissione di file binari, immagini o documenti che fanno uso di caratteri con codifiche estese e potenzialmente pericolose per il transito su particolari sistemi o gateway.

MIME definisce inoltre un insieme di identificatori (“tag”) che consentono di trasmettere, all’interno dello stesso messaggio di posta elettronica, diversi oggetti (quali uno o più messaggi di testo, file binari, immagini,etc..) opportunamente separati in campi, e consente di specificare il tipo di contenuto presente in ciascun campo del messaggio.

Lo standard MIME descrive la struttura dei messaggi di posta elettronica.

La struttura dati MIME è organizzata in diverse entità (parts), ed è di tipo ricorsivo, cioè ogni singola entità può contenerne altre opportunamente formattate ed etichettate secondo le specifiche MIME.

Ciascuna entità è caratterizzata da una intestazione (header) e da un contenuto (Body). Nell’intestazione è presente un campo“Content-Type” che descrive il contenuto della entità in questione; la classificazione avviene specificando dapprima il contesto generale (es. messaggio di testo) e in seguito specificando più in dettaglio la codifica utilizzata (tramite un campo sub-type).

Il contenuto di un’entità può a sua volta contenere un’altra entità MIME, anch’essa costituita di un header e un body, che trasporti informazioni specifiche e classificate dal suo Content-Type specifico. Questo meccanismo consente l’incapsulamento e la strutturazione all’interno dello stesso messaggio di informazioni anche molto complesse, e garantisce una grande flessibilità ed estensibilità.

In MIME sono specificate due entità speciali, dette “composite top-level entities”, che forniscono il contenitore per tutti gli altri tipi di entità: message e multipart.

Un messaggio di posta elettronica in codifica MIME dovrà dunque avere come “scheletro” più esterno necessariamente una di queste due strutture, potrà poi contenere altri oggetti secondo le regole di incapsulamento appena viste.

L’entità message contiene tutti gli header definiti nello standard RFC 822 per i messaggi di posta elettronica, e il suo corpo (Body) può, se necessario, contenere a sua volta altre entità codificate MIME.

La entità multipart consente di inviare all’interno dello stesso messaggio di posta diverse strutture MIME (entità) tra loro indipendenti e ciascuna con la propria codifica.

Oltre a queste speciali top-level entities, appena discusse (“message” e “multipart”), lo standard MIME descrive con precisione la semantica e la sintassi di diversi altri Content-Type quali:

I servizi introdotti sono

L’aggiunta di queste nuove funzionalità allo standard MIME avviene attraverso la definizione di nuovi “tag” di formattazione MIME, che identificano il contenuto di questi campi come “cifrato” o “firmato”, etc…

L’implementazione vera e propria di queste funzionalità si basa invece su tecniche di crittografia a chiave pubblica e sull’utilizzo rigoroso di Certificati di Chiave pubblica in standard X.509.

Le specifiche S/MIME contenute nei documenti RFC 2311 e RFC 2312, descrivono dettagliatamente alcuni nuovi Content-Type MIME utilizzati per associare il contenuto di un campo MIME a delle applicazioni di crittografia a chiave pubblica che consentano di estendere la posta elettronica con i servizi di cifratura e autenticazione.

Per quanto riguarda le operazioni di crittografia S/MIME si basa sulle specifiche internazionali PKCS, tra cui le più utilizzate sono:

I messaggi S/MIME non sono altro che la combinazione di dati in formato MIME e oggetti in formato PKCS secondo queste regole:

Vengono dunque definiti i nuovi content-type:

Alcuni di questi nuovi formati vengono utilizzati per lo scambio di certificati di chiave pubblica, per l’invio di certification request o per altri scopi di gestione dei certificati.

Inoltre, assieme alle etichette MIME, viene impostata l’estensione .p7m per il file in attachment contenente il codice cifrato. Questa è un ulteriore informazione circa il contenuto del campo MIME che garantisce la corretta interpretazione dei dati nel caso in cui il contenuto di questo campo venga salvato su file e perda la formattazione di tipo, l’estensione allora fornirà un’indicazione utile per la decodifica.

Il processo di cifratura o firma dei dati è svolto da una applicazione di crittografia incaricata di questo compito, o a volte dallo stesso Client di posta elettronica.

Il risultato di questo processo verrà poi formattato in un opportuno campo MIME secondo le specifiche S/MIME viste nel paragrafo precedente.

Analogamente in fase di decifratura o verifica il Client effettua tutte le operazioni di decodifica MIME, e demanda le operazioni di crittografia ad un opportuno modulo o ad una applicazione esterna.

Qui di seguito sono riportati due esempi di messaggi di posta elettronica sicura S/MIME: il primo messaggio è cifrato, e il secondo è firmato.

Nel caso in cui si voglia effettuare la firma del documento e cifrare il documento appena firmato, si procede applicando ricorsivamente i due procedimenti precedenti:

E’ dunque evidente la flessibilità e l’estensibilità di questa impostazione, che consente, con grande semplicità, l’utilizzo di molte configurazioni.

Per semplificare la gestione dei percorsi di validazione dei certificati, l’S/MIME prevede una serie di accorgimenti nell’invio dei messaggi di posta elettronica.

Generalmente l’invio di un messaggio contenente del contenuto firmato è accompagnato dall’invio del proprio certificato di chiave pubblica in allegato al messaggio stesso. Il destinatario del messaggio firmato può disporre così immediatamente del certificato di chiave pubblica del mittente e può facilmente verificare la firma del messaggio ricevuto (dopo aver verificato la validità del messaggio allegato).

Questo comodo meccanismo può però essere ulteriormente raffinato. Spesso infatti il destinatario non può verificare direttamente la validità del certificato del mittente allegato con il messaggio, perché non possiede la chiave pubblica della sub-CA che ha firmato quel certificato. Il destinatario è dunque costretto a recuperare il certificato della sub-CA in questione tramite il certificato della root-CA di cui dispone, e successivamente procedere alla verifica del certificato del mittente.

La catena è in genere più lunga, e questo meccanismo semplifica notevolmente i procedimenti di verifica.