INFN
	Security Group

Crittografia per e-mail

v 0.5
8 Maggio 1998

Roberto Cecchini


Indice

Introduzione
Tecniche crittografiche
Certificati
PGP
S/MIME
Appendice
Bibliografia


Introduzione In questo documento vengono brevemente confrontati i due metodi al momento pi¨ convenienti da utilizzare (dal punto di vista del costo e dell'operativitÓ tra diverse piattaforme hardware) per la crittografazione e la firma di messaggi di e-mail: Pretty Good Privacy (PGP e PGP/MIME) e S/MIME. Per un'analisi dettagliata dello stato di queste due proposte di standard, si rimanda al documento dell'IETF: S/MIME and PGP/MIME

La differenza fondamentale tra i due sistemi Ŕ che mentre il primo utilizza una gestione "utente-centrica" delle chiavi pubbliche (il cosidetto web of trust), il secondo impiega una struttura gerarchica di certificazione (le Certification Authorities o CA).


Tecniche Crittografiche

Algoritmi

Le categorie di algoritmi di crittografazione sono fondamentalmente due: convenzionale e a chiave pubblica.

  • Crittografia convenzionale (o simmetrica)
    In questo tipo di crittografia il mittente e il destinatario devono condividere una chiave: un'informazione che permette la crittografazione e la decrittazione dei messaggi. Ovviamente il problema Ŕ come trasmettere in modo sicuro la chiave segreta. Tra gli algoritmi pi¨ comuni DES e IDEA.
  • Crittografia a chiave pubblica (o asimmetrica)
    In questo caso vengono utilizzate due chiavi: una privata, che rimane nota al solo mittente e una pubblica, che viene divulgata. Un messaggio crittografato con una delle due chiavi può venire decrittato con l'altra. Ovviamente deve essere praticamente impossibile risalire dalla chiave pubblica a quella privata. Tra gli algoritmi pi¨ comuni RSA e Diffie-Hellmann.

In pratica, dato che gli algoritmi simmetrici sono circa due ordini di grandezza pi¨ veloci di quelli asimmetrici, si utilizzano entrambi i metodi contemporaneamente. Per ogni messaggio viene generata una chiave random con cui viene crittografato, con un algoritmo simmetrico, e infine questa viene a sua volta crittografata con la chiave pubblica del destinatario e spedita insieme al messaggio.

Message digest

Message digest (o one-way hash) sono stringhe a lunghezza fissa (piccola) calcolate a partire dal messaggio originale. La loro caratteristica Ŕ che Ŕ praticamente impossibile risalire da loro al messaggio e anche trovare due messaggi diversi con lo stesso digest. L'algoritmo pi¨ diffuso Ŕ MD5, anche se recentemente sono stati scoperti alcuni problemi di sicurezza.

Vengono utilizzati per garantire l'integritÓ dei messaggi ricevuti.

Firme digitali

Le firme digitali servono per attribuire con certezza il mittente di un messaggio. Si ottengono crittografando con la chiave segreta del mittente un message digest. In questo modo si ottiene la duplice sicurezza dell'identitÓ del mittente e che il messaggio non Ŕ stato alterato durante il trasporto.


Certificati

I certificati servono per verificare l'identitÓ dei corrispondenti: tra le altre informazioni contengono la loro chiave pubblica e sono firmati da un agente di cui le parti si fidano e che garantisce in questo modo la loro identitÓ. Questo agente viene detto Certificate Authority (CA). In genere i certificati seguono lo standard X.509.

Una CA può emettere un certificato anche per un'altra CA, in questa maniera si possono creare delle catene gerarchiche di certificati (per PGP la cosa Ŕ diversa, dato che ogni utente riveste il ruolo della propria CA). Controllare la validitÓ di un certificato significa quindi risalire la sua catena di autorizzazioni fino a raggiungere quella di una CA di cui il soggetto si fida. I browser in circolazione sono preconfigurati per dare fiducia ad un certo numero (modificabile, ovviamente) di CA ben note, ad es. VeriSign/RSA.

Tra le responsabilitÓ di una CA, oltre ovviamente quella di accertarsi dell'identitÓ dei richiedenti prima di firmare i loro certificati, c'Ŕ quella di gestire le loro scadenze, i loro rinnovi e il mantenimento di liste di certificati non pi¨ validi (Certificate Revocation Lists o CRLs).

In un altro documento viene delineata una possibile organizzazione di una CA per l'INFN utilizzando software di pubblico dominio (SSLeay).


PGP

Pretty Good Privacy (PGP) Ŕ un programma di crittografia a chiave pubblica che utilizza RSA, IDEA e MD5 per firmare e crittografare i messaggi.

Le versioni reperibili, non dovendo sottostare alle restrizioni di esportazione dagli Stati Uniti, fanno uso di chiavi di lunghezza pi¨ che adeguata per qualunque esigenza di sicurezza. Gli ultimi prodotti si adeguano alla proposta di standard PGP/MIME, in concorrenza con S/MIME.

Si basa su due RFC:

  • RFC 1991: PGP Message Exchange Formats,
  • RFC 2015: MIME Security with Pretty Good Privacy.
Il PGP non usa una struttura gerarchica di certificati. Ogni utente mantiene la lista di chiavi pubbliche dei suoi corrispondenti (viene chiamata keyring), ognuna delle quali viene firmata con la propria chiave privata.

╚ possibile scambiarsi i keyring: alle chiavi importate (e quindi firmate dal proprietario) Ŕ possibile assegnare diverse gradazioni di "fiducia" che permettono di costruire il cosiddetto web of trust (l'equivalente della struttura gerarchica dei certificati).

OperativitÓ

Al momento ci sono due versioni in uso: la vecchia (2.6.3i), disponibile su quasi tutte le piattaforme e la nuova (5.x) per Windows (tra poco Mac e Unix). Le chiavi generate dalla nuova versione (almeno quella reperibile in rete) non sono compatibili con quelle della vecchia, mentre Ŕ vero il vice versa.

Per garantire la massima compatibiltÓ Ŕ necessario utilizzare solamente la vecchia versione (2.6.3i) e rinunciare alla possibilitÓ (quando esiste) di comporre mail MIME.

Unix
L'utilizzo classico Ŕ dalla riga di comando, facendo uso di file di appoggio o delle pipe.
Alcuni clienti di e-mail (ad esempio xfmail e pine) lo gestiscono in modo abbastanza trasparente. Attenzione per˛ perchŔ alcuni (ad es. tkrat) producono mail MIME, che non sono utilizzabili in modo semplice da altri clienti (ad esempio Pine).

Windows
Si trovano delle shell interattive che permettono di operare in modo abbastanza semplice tramite la clipboard.

Macintosh
Al momento Ŕ disponibile solo la vecchia versione, che lavora sulla clipboard.

Un ipotetico scenario di utilizzo Ŕ il seguente:
  • L'utente installa sulla propria piattaforma il software PGP e genera la coppia di chiavi.

  • L'utente pubblicizza la propria chiave pubblica inviandola ad un key server e/o ai suoi corrispondenti.

  • L'utente si procura la chiave pubblica dei suoi corrispondenti da un key server o direttamente (in entrambe i casi, sarÓ sua cura accertarsi che la chiave sia corretta, ad esempio telefonando al corrispondente e verificando il key fingerprint). Le chiavi vanno firmate e inserite nel proprio keyring.
Pu˛ essere utile installare un key server specifico per l'INFN, operazione che non sembra particolarmente difficoltosa. In alternativa si possono utilizzare i key server giÓ esistenti. In ogni caso il concetto fondamentale Ŕ che la verifica della correttezza delle chiavi Ŕ demandata all'utente stesso.


S/MIME

S/MIME (Secure/Multipurpose Internet Mail Extensions) Ŕ una proposta di standard per la crittografazione e firma dei messaggi di posta elettronica. Utilizza RSA, RC2 e MD5 per la crittografazione e firma e certificati digitali nel formato X.509. La versione 2 Ŕ descritta in due documenti:

  • RFC 2311: S/MIME Version 2 Message Specification.
  • RFC 2312: S/MIME Version 2 Certificate Handling.

Le implementazioni reperibili, dovendo sottostare alle restrizioni di esportazione dagli Stati Uniti, fanno uso di chiavi di lunghezza inadeguata (512 bit per RSA e 40 bit per RC2). (In un report di alcuni eminenti crittografi, Minimal Key Lenghts for Symmetric Ciphers to Provide Adequate Commercial Security, una chiave di 40 bit viene dichiarata decrittabile in una settimana facendo uso di un comune PC).

Per questo motivo non sembra probabile che la versione 2 venga accettata come standard IETF (Ŕ in preparazione la versione 3).

Dopo la pubblicazione dei sorgenti di Netscape Communicator v5 sono disponibili versioni (al momento per alpha, sun, linux e windows) con algoritmi prima riservati al mercato USA. (Sarebbe possibile anche con la versione 4.04, ma Ŕ necessaria una modifica dell'eseguibile, proibita dalla licenza d'uso).

OperativitÓ

Netscape Communicator (4.x) e Microsoft Outlook (fornito con Internet Explorer 4) sono entrambi in grado di generare messaggi di questo tipo (compatibili tra di loro). La gestione Ŕ molto buona: la crittazione e decrittazione viene eseguita in modo trasparente, come pure la gestione dei certificati dei destinatari, che vengono automaticamente scaricati dai messaggi ricevuti. Manca una gestione automatica delle CRL (Ŕ prevista invece, almeno per Netscape, per i certificati dei server web).

Sebbene le chiavi generate da Communicator siano di 512 bit, Ŕ possibile utilizzarne di prodotte esternamente da 1024 bit (tramite SSLeay); lo stesso non sembra possibile con Outlook (per ulteriori dettagli vedere il documento specifico).

Il problema principale, prescindendo dalla bassa sicurezza, Ŕ legato alla necessitÓ dell'esistenza di un certificato per ogni destinatario. Fintanto che tutti i possibili destinatari non saranno certificati da una qualche CA (situazione per ora ben lontana dall'essere realizzata) questo metodo si presta bene solo per la corrispondenza all'interno di una singola organizzazione, che pu˛ abbastanza facilmente organizzarsi come CA.

Un ipotetico scenario di utilizzo Ŕ il seguente:

  • L'utente scarica nel propio browser il certificato della CA INFN (interattivamente, o, se paranoico, con altri metodi).

  • L'utente richiede interattivamente il proprio certificato, che gli viene spedito per e-mail. Una volta che lo ha caricato nel proprio browser (Netscape 4.x) Ŕ pronto per inviare mail firmati e crittografati ad altri corrispondenti muniti di un certificato (non necessariamente della stessa CA: in questo caso Ŕ necessario procurarsi anche il certificato della CA).

  • Lo scarico dei certificati dei corrispondenti pu˛ avvenire interattivamente (se certificati dalla CA INFN o inseriti in una delle directory LDAP include nel browser) o automaticamente alla ricezione del primo mail firmato dallo stesso.

Tutti i punti di sopra sono stati sperimentati (il software usato per la gestione della CA INFN Ŕ SSLeay, di pubblico dominio). Per una gestione completa di una CA rimangono da sperimentare i punti seguenti:
  • Gestione dei rinnovi dei certificati utenti e della CA;

  • Revoca dei certificati e CRL.


Appendice

La tabella seguente riassume le caratteristiche salienti dei sistemi sopra descritti.

  PGP X.509 - v3
Contenuto certificati chiave pubblica, indirizzo di e-mail e "grado di fiducia" Pienamente estendibile, può includere qualunque informazione
Struttura CA Web of trust Gerarchica
Relazione CA - Utente Ogni utente è la propria CA. Si può assegnare un "grado di fiducia" agli altri soggetti (altre CA). L'utente deve fidarsi di almeno una CA. Le CA possono controllare come viene delegata la loro fiducia nei soggetti e nelle altre CA
Convalida certificati Una volta che un certificato è aggiunto ad un keyring, è valido fino ad esplicita revoca: non esiste data di scadenza Offline. Previste estensioni per una convalida online
Revoca certificati La revoca viene comunicata personalmente, non esistono CRL Meccanismi sofisticati di CRL. Estensioni per metodi online


Bibliografia

  1. S/MIME and PGP/MIME (documento imc).
  2. RFC 1991: PGP Message Exchange Formats.
  3. RFC 2015: MIME Security with Pretty Good Privacy.
  4. S/MIME FAQ (documento RSA).
  5. RFC 2311: S/MIME Version 2 Message Specification.
  6. RFC 2312: S/MIME Version 2 Certificate Handling.
  7. Minimal Key Lenghts for Symmetric Ciphers to Provide Adequate Commercial Security
 

Roberto Cecchini

URL: http://security.fi.infn.it/documenti/cripmail.html