| Home / Indice sezione | www.icosaedro.it | |
Crittografia - ImplementazioniUna volta appresi i concetti fondamentali degli algoritmi di crittazione a chiavi asimmetriche, rimane da affrontare il capitolo forse ancora più complesso di tutta la questione: quello dei formati di rappresentazione, e quello della archiviazione e della certificazione delle chiavi pubbliche. Sono tutti argomenti che non aggiungono molto a livello concettuale, per cui ai più basterà scorrere rapidamente i vari paragrafi, magari soffermandosi su quelli che descrivono i programmi di pratico utilizzo, come PGP e GnuPG.
Pubblicato nel 1998 in stretta collaborazione con NAI (vedi paragrafo successivo su PGP), questo standard Internet descrive il formato dei messaggi di posta elettronica e degli articoli dei newsgroup quando essi devono essere crittati o firmati attraverso un qualche algoritmo a chiavi asimmetriche, in modo da favorire l'interoperabilità dei vari programmi.
OpenPGP prevede l'inserimento nel corpo del messaggio di varie linee dal formato definito che permettono di distinguere il messaggio vero e proprio dalla firma digitale e dalle altre informazioni tecniche necessarie, come il tipo di digest e gli algoritmi a chiavi simmetriche e asimmetriche utilizzati, l'algoritmo di compressione, l'elenco in ordine di preferenza dei sistemi a chiavi pubbliche supportati dal mittente. Sono previsti anche i messaggi per la richiesta di certificazione della chiave pubblica e per la sua revoca, che vanno inviati agli appositi server che custodiscono le chiavi.
Ecco come appare un messaggio email corredato di firma digitale:
Date: Sun, 20 Jan 2002 16:18:01 CET
From: Umberto Salsi <salsi@icosaedro.it>
To: Concimi Biologici s.r.l. <vendite@concimi-biologici.it>
Subject: Conferma ordinazione
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Data: 20 gennaio 2002
Oggetto: Conferma ordinazione
Spett.le Concimi Biologici s.r.l.,
con la presente confermo l'ordinazione per il seguente materiale:
stallatico stagionato standard q.li 2
Poiche' domani, lunedi', non saro' presente, come da accordi telefonici
depositerete il materiale direttamente nel mio giardino (mi raccomando,
non sul vialetto!).
Paghero' per il servizio Euro 100,00 con bonifico bancario.
Distinti saluti,
Umberto Salsi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8TlFOviz2zXfpKa4RAiN+AJ0ZL7f2po4gXT2+AQ7cg2PN4iJTOgCdF+2E
zvoJ8w7aTUss/uLN2eEM10Q=
=jF1c
-----END PGP SIGNATURE-----
L'aspetto complessivo del messaggio non è molto invitante, comunque sono facilmente distinguibili la parte di messaggio in prosa dalla parte che contiene la firma. Nel prossimo paragrafo vedremo come il formato MIME venga in aiuto al client di posta elettronica per presentare all'utilizzatore una interfaccia più versatile e amichevole.
Tra gli algoritmi a chiavi asimmetriche citati dallo standard ci
sono: RSA, ElGamal, DSA, Diffie-Hellman.
Tra gli algoritmi a chiavi
simmetriche previsti dallo standard ci sono: IDEA, 3DES, DES, CAST5,
Blowfish, AES.
Tra gli algoritmi digest previsti dallo standard
ci sono: MD5, RIPEMD-160, SHA-1.
Tra gli algoritmi di compressione
previsti dallo standard ci sono: ZIP (RFC 1951), ZLIB (RFC 1950).
Tutto questo non significa che un programma conforme allo standard OpenPGP debba necessariamente supportare tutti gli algoritmi elencati: la specifica prevede alcuni algoritmi come obbligatori, ed altri come facoltativi. Inoltre alcuni programmi gratuiti come GnuPG, sebbene peraltro conformi, non possono includere alcuni algoritmi perché tuttora coperti da brevetto, come IDEA.
Questi due RFC descrivono il formato MIME da adottare per i messaggi di posta elettronica. Il formato MIME è uno standard Internet RFC che permette di descrivere il contenuto di un messaggio email: oltre al solito testo ASCII, diventa possibile includere anche altri tipi di dati quali immagini, suoni, documenti allegati, ecc. In particolare, l'RFC 2015 descrive i tipi MIME introdotti espressamente per il supporto del programma PGP, mentre l'RFC 3156 aggiorna il precedente e lo estende verso OpenPGP.
Ecco come appare un messaggio corredato di firma digitale una volta rappresentato nel formato OpenPGP/MIME (tratto da un simpatico esempio contenuto nell'RFC 3156):
From: Michael Elkins <elkins@aero.org>
To: Michael Elkins <elkins@aero.org>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5;
protocol="application/pgp-signature"
--bar
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
=A1Hola!
Did you know that talking to yourself is a sign of senility?
It's generally a good idea to encode lines that begin with
From=20because some mail transport agents will insert a greater-
than (>) sign, thus invalidating the signature.
Also, in some cases it might be desirable to encode any =20
trailing whitespace that occurs on lines in order to ensure =20
that the message signature is not invalidated when passing =20
a gateway that modifies such whitespace (like BITNET). =20
me
--bar
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
HOxEa44b+EI=
=ndaj
-----END PGP MESSAGE-----
--bar--
C'è tutta una serie di caratteri apparentemente casuali, come
i vari ``=20'' che fanno parte della rappresentazione
quoted-printable, e che non hanno realmente a che fare col nostro
discorso, ma almeno così vediamo come funzionano le cose nella loro
cruda realtà! Ho evidenziato in grassetto le righe specifiche
del formato MIME. Grazie a questo formato, un programma client di
posta capace di interpretare MIME e OpenPGP, sarà in grado
di presentare una interfaccia amichevole all'utilizzatore: al posto
dell'intricata sequenza di codici e righe di separazione, per esempio,
potrebbe visualizzare semplicemente il messaggio in prosa depurato dai
vari caratteri speciali, e mostrare magari a lato una icona col simbolo
della firma acceso ad indicare che il messaggio è firmato e che
la firma è valida (se la firma non fosse valida, al posto della
icona della firma potrebbe apparire un simpatico volto mascherato...).
Per una discussione introduttiva al formato MIME, vedere ad esempio www.icosaedro.it/articoli/protocolli2.html,
che contiene anche i riferimenti bibliografici completi.
Questo programma ha una storia lunga e travagliata: su [GARF95]
c'è raccontanto tutto, dal 1977 al 1995. Detta in breve, Phil
Zimmermann (nella foto) cominciò a scrivere il suo programma subito
dopo l'annuncio dell'invenzione di RSA; tuttavia dovette scontrarsi
con le restrizioni imposte dal brevetto, che non gli permisero di
commercializzare il suo programma.
A partire dal 1991 il programma PGP cominciò a circolare via Internet in una forma semi-clandestina, diffondendosi rapidamente, sorgenti inclusi. Alla questione del brevetto si aggiunsero le indagini del governo USA sulla presunta violazione delle leggi contro l'esportazione delle tecnologie crittografiche, ed RSA era proprio uno degli algoritmi interessati. Per sanare un po' la situazione, RSA Data Security finì per rilasciare una implementazione particolare delle librerie che implementavano i suoi algoritmi crittografici (la libreria RSAREF), ma con particolari restrizioni per consentirne l'uso all'interno di programmi gratuiti come PGP e notoriamente poco efficiente; altri escamotage permisero anche l'esportazione del programma, da cui nacquero le versioni "international".
A complicare ulteriormente le cose, a partire dagli originali sorgenti prodotti da Zimmermann sono state sviluppare altre versioni del programma, in particolare la versione del MIT, che usa le RSAREF per il suo PGP 2.6.2.
A partire dai sorgenti del MIT sono derivate altre versioni, come la versione internazionale 2.6.3i ottenuta reintegrando nel programma le originali librerie MPILIB di Zimmermann: siccome il brevetto RSA è riconosciuto solo all'interno degli USA, questa versione è perfettamente legale negli altri paesi. Unico problema: l'algoritmo IDEA, usato da PGP per la crittazione (ma non per la firma digitale, dove non serve) è tuttora brevettato in tutto il mondo, e per gli usi commerciali si richiede il pagamento di una licenza (v. il paragrafo su IDEA nella sezione sugli algoritmi a chiavi simmetriche).
Comunque, alla fine Zimmermann col suo programma finirono alla Network
Associates Inc., dove Zimmermann ha continuato a sviluppare il suo
programma. Nell'autunno 2001, Zimmermann ha lasciato NAI, ufficialmente
per via del suo disaccordo con la scelta dell'azienda di non rendere
più disponibili i sorgenti del programma: da paladino della
privacy, Zimmermann sostiene che solo con i sorgenti disponibili gli
esperti possono valutare la reale sicurezza di un programma, e di
conseguenza solo così poi gli utenti potranno fidarsi di esso.
Non mi dilungo oltre, ed invito a visitare la home page dell'autore su www.philzimmermann.com.
Attualmente PGP è di proprietà di Network Associates Inc. (www.nai.com) e il programma può essere scaricato da www.pgp.com. Il programma è gratuito per usi non commerciali, ed è disponibile per vari sistemi operativi. Lo scorso ottobre 2001, NAI ha annunciato di voler scorporare la divisione che si occupa del mantenimento del programma PGP per la posta elettronica, pur continuando lo sviluppo degli altri suoi programmi che fanno uso delle tecnologie crittografiche derivate da PGP.
Nel sito www.pgpl.com
sono archiviate tutta una serie di versioni gratuite storiche e recenti
del programma e per vari sistemi operativi (MS Windows, MacOS, Atari,
Unix, Linux, ecc.), comprese:
$ pgp
Pretty Good Privacy(tm) 2.6.3ia - Public-key encryption for the masses.
(c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 1996-03-04
International version - not for use in the USA. Does not use RSAREF.
...
$ pgp
Pretty Good Privacy(tm) Version 6.5.8
(c) 1999 Network Associates Inc.
Uses the RSAREF(tm) Toolkit, which is copyright RSA Data Security, Inc.
Export of this software may be restricted by the U.S. government.
...
Premettiamo che per inviare un messaggio crittato a varie persone, i programmi permettono di eseguire la crittazione usando le rispettive chiavi pubbliche in combinazione, in modo che il messaggio sia decrittabile da tutti i destinatari usando ciascuno la propria chiave privata. E fin qui tutto bene: si tratta di una utile funzionalità che risparmia di dover inviare tanti messaggi diversi, ciascuno crittato con una diversa chiave pubblica.
Veniamo ora alla questione che ci interessa. E' una storia interessante ed istruttiva, conviene vederla in un certo dettaglio. A partire da Windows NT 4 e seguenti, e da Windows 95 e seguenti, i sistemi operativi di Microsoft includono la libreria CryptoAPI, una serie di utilità per la crittazione sfruttate da molte applicazioni che girano su questo sistema operativo (a cominciare dallo stesso Internet Explorer).
Con il rilascio del Service Pack 5 per Windows NT, Microsoft distribuì per errore i programmi nella forma non stripped, cioè con incluse tutte le informazioni per il debugger, come i nomi delle funzioni e i nomi delle variabili così come apparivano nei sorgenti: niente di grave, per la verità, e nulla che possa permettere di ricostruire i sorgenti originari, ma questo ha dato la possibilità ad alcuni hacker curiosi di indagare un po'. Dall'analisi di queste informazioni venne individuata nel codice CryptoAPI una misteriosa variabile di nome ``_NSAKEY''. A cosa servirà mai questa chiave? la sigla ``NSA'' ha qualcosa a che vedere con la National Security Agency? si tratta forse di una chiave pubblica che consente al possessore della corrispondente chiave privata di decrittare tutti i messaggi generati dalle applicazioni che usano le CryptoAPI?
Interrogata al riguardo, Microsoft smentisce decisamente, e parla semplicemente di un ``nome di variabile scelto in modo sfortunato''. Però intanto alcuni esperti di crittografia suggeriscono di evitare i programmi che usano le CryptoAPI nelle applicazioni dove è richiesta la massima sicurezza.
Tra le applicazioni che usano sicuramente queste librerie c'è PGP 6.0.2; sicure le altre versioni precedenti e successive dello stesso programma; dalla versione 7 in poi di PGP nulla si può dire: i sorgenti non sono disponibili.
Rilasciato nella sua prima versione completa nel 1999,
GnuPG ha recentemente ottenuto il sostegno ufficiale
del ministero dell'economia e della tecnologia tedesco
che gli ha riconosciuto il suo importante contributo alla protezione
della privacy. GnuPG implementa i principali algoritmi per la crittazione
con chiavi asimmetriche, come RSA e DSA, e i principali algoritmi per
la crittazione con chiavi simmetriche, come 3DES, CAST e AES. Manca,
invece, il supporto per quegli algoritmi che sono brevettati, come IDEA;
lo stesso RSA è stato aggiunto ufficialmente solo nell'autunno
del 2000 con lo scadere del prevetto su questo algoritmo. Inoltre GnuPG
è conforme a OpenPGP, anche se non è in grado di generare
o interpretare OpenPGP/MIME: quest'ultima funzionalità è
a carico del client di posta o altro software in grado di interpretare
correttamente il formato MIME. GnuPG è distribuito con licenza
GNU GPL, e dunque sono disponibili i sorgenti del programma. Il programma
è gratuito.
Dal sito www.gnupg.org si accede alla documentazione, al download del programma per vari sistemi operativi, e ad altri strumenti collegati al programma base, come le interfaccie grafiche, le patch per l'integrazione coi programmi di posta elettronica, ecc.
La versione 1.0.6 correntemente disponibile, nel suo packaging standard, fornisce il supporto per i seguenti algoritmi:
$ gpg --version
gpg (GnuPG) 1.0.6
Copyright (C) 2001 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
Home: ~/.gnupg
Supported algorithms:
Cipher: 3DES, CAST5, BLOWFISH, RIJNDAEL, RIJNDAEL192, RIJNDAEL256, TWOFISH
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA, ELG
Hash: MD5, SHA1, RIPEMD160
Dal sito ufficiale si può scaricare la documentazione e la patch per il supporto dell'algoritmo di crittazione IDEA, che è l'unico supportato da PGP 2.6 e precedenti.
In questa tabella metto a confronto due programmi per la crittazione e la firma digitale molto popolari: PGP e GnuPG. Di ogni programma riporto la lista degli algoritmi supportati per la gestione delle chiavi pubblica e privata, gli algoritmi per la crittazione, gli algoritmi per il digest e gli algoritmi per la compressione. I dati che ho raccolto sono ancora parziali e da verificare, ma l'obiettivo è di confrontare l'interoperabilità dei due programmi.
Nella bibliografia non sono riportati i riferimenti agli algoritmi digest e agli algoritmi di crittazione a chiavi simmetriche, che si trovano nella rispettive sezioni di questa raccolta di documenti.
Gli algoritmi di compressione vengono applicati ai messaggi prima che essi siano crittati: riducendo la ridondanza, si rafforza la sicurezza.
| PGP v. >=2.6 |
GnuPG v. >=1.0.6 |
|
|---|---|---|
| Algoritmi di crittazione a chiavi asimmetriche | ||
| RSA | Sì | Sì |
| DSA | Sì (v.>=5) | Sì |
| ElGamal | Sì (v.>=?) | Sì |
| Algoritmi di crittazione a chiavi simmetriche | ||
| 3DES (168 b) | Sì (v.>=5) | Sì |
| IDEA (128 b) | Sì | No (v. nota 2) |
| CAST-128 (128 b) | Sì (v.>=5) | Sì |
| RIJNDAEL (AES) | Sì (v.>=7.0.1) | Sì |
| Twofish (256 b) | Sì (v.>=7) | Sì |
| Blowfish | No | Sì |
| Algoritmi di digest | ||
| SHA-1 (160 b) | Sì (v.>=5) | Sì |
| MD5 (128 b) | Sì | Sì |
| RIPE-MD/160 (160 b) | Sì (v.>=5) | Sì |
| Algoritmi di compressione | ||
| Senza compressione | Sì | Sì |
| ZIP [RFC1951] | Sì | Sì |
| ZLIB [RFC1950] | Sì | Sì |
NOTA 1. "PGP", "Pretty Good" e "Pretty Good Privacy" sono marchi
registrati di Network Associates, Inc.
NOTA 2. IDEA è brevettato fino al 2007; è disponibile
come patch non ufficiale per GnuPG (ftp.gnupg.org/pub/gcrypt/contrib).
Altre considerazioni sparse sulla compatibilità per chi usa PGP 2.6:
www.pgpl.org in forma di
sorgente o di binario nelle versioni per i vari sistemi operativi.
Altre considerazioni sparse sulla compatibilità per chi usa PGP 6.5.8:
www.pgpl.org
nelle versioni per i vari sistemi operativi. Esiste anche la versione a linea
di comando retro-compatibili con PGP 2.6.
pgp -ka .pgp/secring.pgp.
Altre considerazioni sparse sulla compatibilità per chi usa GnuPG v. 1.0.6:
www.gnupg.org in forma di sorgente e in forma binaria. Sono disponibili vari
strumenti ed interfacce grafiche per vari sistemi operativi.
Ricordo che il formato OpenPGP prevede che le chiavi pubbliche riportino
anche un elenco degli algoritmi crittografici supportati dai rispettivi
proprietari, sicché in generale ci possiamo aspettare un buon
livello di interoperabilità tra programmi diversi, purché recenti
e conformi a OpenPGP.
Le versioni più recenti dei programmi di crittografia sono senzaltro
consigliabili: PGP 6.5.8 e GnuPG 1.0.6 sono entrambi ottimi prodotti di
uso pratico e ampiamente interoperanti.
Le chiavi pubbliche, soprattutto se a 1024 bit o più, sono piuttosto lunghe e difficili da manipolare manualmente, e perciò sono adatte solo se scambiate in forma elettronica come file. Ad esempio, la mia chiave pubblica a 1024 bit è questa:
$ gpg --armor --export salsi
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
mQGiBDvezdkRBADyO25PfbGeYtcQegmBsLfmTGh3iQkjUKFAlQTbbIWERbxZX8rX
koC1BwubfkHDSjdlOR2dPqT8a2aBRbBcj61k+lPlCiDcMQB6GyRX9i9mVKMztoW0
LCUJY5OF5Ud5hg5kNm7pJ31JwtCWQyimjr9vEDMRdqSQT6VVPExwspPVvwCguKXp
2HeMUa3kEenvJWz/9P3zJ4sD/jurzoGERIHFGl0h2aUAhmqmt1HL3MyP7/4sleVe
1972KL0prCUwkQp7j+HzP0s0iDGNvE7hBNginLMPi+EDcVmpt20KOMcKGqyRyfcG
EuCubmGK+HN8v8+JnEI62punKQz4mtwqEa7I6Unj4aC41j9nV6oqMUV2Xe+GbekD
y0anA/9gbeZBhF9jQt1ds/bzvD8T19mSYD0pwGWLMuqCI+uzYTmlbBpPOELedFAb
VCkGbryXIA95T8lzyvk0hXEyO8un5WLTE6T/QvX9GgG6VdaQziBxVZ6cz5ByGcUK
JVnJz2cIXFIHb/krDuTA5Uom/HDpiqK2LA9i9p2lvc8+AYl1gLQnVW1iZXJ0byBT
YWxzaSA8dW1iZXJ0by1zYWxzaUBsaWJlcm8uaXQ+iFcEExECABcFAjvezdkFCwcK
AwQDFQMCAxYCAQIXgAAKCRC+LPbNd+kprnfQAJoC98WrGtER+2VCq+aE5NAwJDOu
CgCeIBjyhLcH5buH039XiSmBvAk8uoK5AQ0EO97OEhAEAJ1kEpiuOm+bEPELP01t
Eg8RSHbp2NIEzvdor2D177ROsNsHmpnzCEM1DK+c5X9wWa5CJ7Iic0XYFFcxxQxj
rXgPj8o+pnj2RVhJIg1qydtOl6MjODBd4uNFHkGuEKzFluJkD0Q9cvTY/nqVCHWx
Bhg8FIrOaXVxugSQIIZizGg/AAQLA/9/ba0IQMG+C0mwRwtCPvlzjSUNVDhBkW2Q
u2N/wuNK9T5ZRHNnYL+Vh5EWKj7Ro61ma9cex1YB2zlucqEFsIBmzOU0meEmxF65
eISfurmfHXQVm1zg6+Le1Aac56RhE3AFyQlKaeAHTjbriQv7MpuWqehGJxwcXL0j
HM8V7CdfiIhGBBgRAgAGBQI73s4SAAoJEL4s9s136SmuZbcAoK3SbRO2WRKzbu8t
a2UM3UYZSU96AJsFCK5GLkYielamW/HLWECTGdPoiQ==
=QNEu
-----END PGP PUBLIC KEY BLOCK-----
Ecco perché troveremo più spesso riportato il fingerprint della chiave, cioè il digest della chiave pubblica, oppure il key ID che è ancora più breve. Ecco ad esempio il mio fingerprint:
Key fingerprint = B957 FB00 10F5 A770 4A26 2D80 BE2C F6CD 77E9 29AE
In un messaggio email o in un biglietto da visita basta indicare invece il solo key ID, cioè le ultime cifre del fingerprint, facili da dettare per controllo anche via telefono:
Key ID = BE2C F6CD 77E9 29AE
Naturalmente queste forme abbreviate non sostituiscono la chiave pubblica, ma permettono di fare un controllo incrociato: quando visualizzeremo il nostro mazzo di chiavi, vedremo anche tutti i fingerprint per un rapido controllo incrociato. Ecco un esempio di come potrebbe apparire un mazzo di chiavi con le rispettive fingerprint:
$ gpg --fingerprint
/home/salsi/.gnupg/pubring.gpg
------------------------------
pub 1024D/77E929AE 2001-10-30 Umberto Salsi <salsi@icosaedro.it>
Key fingerprint = B957 FB00 10F5 A770 4A26 2D80 BE2C F6CD 77E9 29AE
sub 1024g/9D66608C 2001-10-30
pub 1024D/DB42A60E 1999-09-23 Tizio Tiziani <tizio@qualcosa.it>
Key fingerprint = 8A20 8686 2BD6 9DFC 65F6 ECC4 2191 80CD 0B31 C60B
sub 2048g/961630A2 1999-09-23
pub 2048R/B28B9B51 2001-08-02 Caio Caiesi <caio@altroancora.it>
Key fingerprint = 94 A4 F7 B5 46 96 D6 C7 A6 73 F2 98 C4 8C D0 E0
NOTA: per curiosità, osserviamo che le fingerprint di Salsi e Tizio usano 40 cifre esadecimali, per un totale di 160 b: si tratta dei digest SHA-1 a 160 b delle loro chiavi pubbliche; invece il sig. Caio usa una vecchia chiave RSA proveniente da PGP 2.6, dove il fingerprint è il digest MD5 a 128 b della sua chiava pubblica.
Le chiavi pubbliche possono contenere la firma digitale di terze persone, e così diventare arbitrariamente lunghe. Questo meccanismo permette però di stabilire relazioni di fiducia tra gruppi di persone, estendendo transitivamente le relazioni di validità della chiavi. Vedremo subito nel dettaglio il significato di questo meccanismo noto come ``Web-of-trust''.
I programmi come PGP e GnuPG prevedono un modello distribuito per la certificazione delle chiavi pubbliche, e le operazioni di validazione sono essenzialmente manuali. Ogni utilizzatore del programma ha la responsabilità di assegnare alle chiavi pubbliche in suo possesso la validità e il livello di fiducia delle chiavi del suo mazzo di chiavi.
Vediamo allora quali sono le due proprietà fondamentali della chiavi pubbliche secondo il modello del Web-of-trust:
I programmi PGP e GnuPG permettono di modificare in ogni momento la validità e il livello di fiducia delle chiavi, man mano che si acquisiscono informazioni sugli interlocutori.
La gestione delle chiavi pubbliche secondo il modello OpenPGP è piuttosto complessa, e richiede un certo impegno da parte dell'utilizzatore che ne voglia sfruttare le potenzialità. Per un uso elementare del programma basterà impostare la validità e indicare come "No" il livello di fiducia: successivamente, e in qualsiasi momento, potrà modificare queste impostazioni.
Nel modello di certificazione delle chiavi OpenPGP non esistono autorità centrali di certificazione; si tratta piuttosto di un sistema distribuito di relazioni di fiducia gestite dai singoli utilizzatori e che si propagano come in una rete, da cui appunto il nome ``Web-of-trust''.
Vediamo finalmente in azione tutto l'apparato crittografico visto finora applicato a un caso concreto. Siccome ho il pollice verde e curo con assiduità il mio bel giardino, non manco mai di provvedere periodicamente alla sua concimazione con prodotti naturali ed ecologici. Ripropongo perciò qui il mio email che avevamo già visto in un paragrafo precedente, e che ora acquista un suo senso:
Date: Sun, 20 Jan 2002 16:18:01 CET
From: Umberto Salsi <salsi@icosaedro.it>
To: Concimi Biologici s.r.l. <vendite@concimi-biologici.it>
Subject: Conferma ordinazione
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Data: 20 gennaio 2002
Oggetto: Conferma ordinazione
Spett.le Concimi Biologici s.r.l.,
con la presente confermo l'ordinazione per il seguente materiale:
stallatico stagionato standard q.li 2
Poiche' domani, lunedi', non saro' presente, come da accordi telefonici
depositerete il materiale direttamente nel mio giardino (mi raccomando,
non sul vialetto!).
Paghero' per il servizio Euro 100,00 con bonifico bancario.
Distinti saluti,
Umberto Salsi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8TlFOviz2zXfpKa4RAiN+AJ0ZL7f2po4gXT2+AQ7cg2PN4iJTOgCdF+2E
zvoJ8w7aTUss/uLN2eEM10Q=
=jF1c
-----END PGP SIGNATURE-----
Nel corpo dell'email sono chiaramente identificabili il mio messaggio in prosa e la firma digitale. Le due sezioni vengono marcate con le stringhe convenzionali definite dal formato OpenPGP (RFC 2440). La sequenza di caratteri apparentemente casuali che compare nella firma è il digest del messaggio crittato con DSA. Nello specifico, il programma che ho usato qui è GnuPG v. 1.0.6, come del resto si può leggere chiaramente dai commenti.
La ditta Concimi Biologici s.r.l. può subito verificare la mia firma digitale. Poiché sono loro cliente abituale, non dovranno neppure fare lo sforzo di procurarsi la mia chiave pubblica, che è già memorizzata nel loro computer. Il loro programma gli confermerà, magari con un bel "SIGNATURE OK" lampeggiante, che il messaggio è autentico e che possono dare seguito alla mia ordinazione in piena fiducia.
Essendo la posta elettronica un mezzo di comunicazione veloce ed informale, per convenzione spesso si trascurano tutti quei convenevoli e quei preamboli burocratesi tipici dei documenti cartacei. Tra le omissioni più frequenti ci sono la data e le generalità esatte del mittente e del destinatario: infatti nell'ambito della posta elettronica, si dà per scontato che le informazioni già contenute nella intestazione standard siano sufficienti, ed in effetti in generale è così. Esaminiamo invece attentamente quello che io ho scritto in questo email.
Nel corpo del messaggio appaiono due ridondanze curiose: la data e il nome della ditta. Queste due informazioni sono già contenute nella intestazione, perciò perché riprodurle di nuovo? La ragione è semplice: la firma digitale interessa solo il corpo del messaggio, mentre l'intestazione potrebbe essere anche falsificata. Senza data e senza nome della ditta fornitrice esplicitamente indicati nel corpo, un "amico" perditempo che fosse entrato per caso in possesso del messaggio potrebbe ritagliare il corpo del messaggio ed inserirlo in tanti email falsificati diretti ad altre ditte, oppure potrebbe inviare più volte l'ordinazione in diversi giorni. Le conseguenze per il mio bellissimo giardino all'inglese sono facilmente immaginabili, e per il mio portafogli, pure...
La morale di questo discorso è che, siccome la firma digitale interessa solo il corpo del messaggio, le uniche informazioni verificabili sono quelle messe lì, ed è lì che si deve esprimere in modo compiuto e non ambiguo il messaggio, specificando tutto quello che normalmente si scriverebbe su di un ordinativo cartaceo.
Nota finale. La ditta Concimi Biologici s.r.l. non esiste, e io non concimo mai le mie piante; a dirla tutta, di piante non ne ho proprio, neanche un vasetto di prezzemolo; e per quanto riguarda il giardino, anche se ne avessi uno, credo che lascerei libero sfogo alla natura di farci crescere quello che vuole. Da parte mia, quando ho tempo leggo, studio cose che mi interessano e qualche volta scrivo un po' di quello che ho capito.
Ci sono diversi modi per eseguire la registrazione della chiave pubblica:
www.complaw.com/pgp/keyserver.html.
x-hkp://www.keyserver.xy/pks/lookup?op=get&search=0x123456789ABC
Se il browser non riconosce il protocollo x-hkp://, bisogna
indicare esplicitamente la porta, di solito la 11371, usando un URL
più convenzionale:
http://www.keyserver.xy:11371/pks/lookup?op=get&search=0x123456789ABC
Una lista più completa ed aggiornata si trova in
www.openpgp.net.
Questo è un elenco, assolutamente parziale, di keyserver disponibili:
blackhole.pca.dfn.de
certserver.pgp.com
horowitz.surfnet.nl
keyserver.linux.it
keys.pgpi.net
math-www.uni-paderborn.de/pgp/
pgp.ai.mit.edu
pgpkeys.mit.edu
pgp.surfnet.nl
wwwkeys.at.pgp.net
wwwkeys.ch.pgp.net
wwwkeys.cz.pgp.net
wwwkeys.de.pgp.net
www.keyserver.net
wwwkeys.nl.pgp.net
wwwkeys.pgp.net
wwwkeys.us.pgp.net
www.openpgp.net/pgpsrv.html
Questo standard ITU descrive il formato dei certificati pubblici per la registrazione, la revoca e la verifica delle chiavi pubbliche e delle chiavi segrete. Tra il 1988 e il 1995 sono state approvate tre versioni, numerate da 1 a 3. Un certificato X.509 riporta le seguenti informazioni:
Il formato X.509 non fa riferimento ad alcun particolare algoritmo a chiavi simmetriche o asimmetriche da usare, e può essere usato per la certificazione delle chiavi pubbliche e nei protocolli di rete come SSL.
A titolo di esempio, ecco come appare un certificato per il mio serverino: le informazioni in esso contenute sono autenticate dalla firma digitale che contiene la mia firma e la firma della CA che l'ha convalidata (tutti i dati sono di fantasia, perciò non si tratta di un certificato reale, e il soggetto richiedente e l'autorità certificante sono inventati; la versione di X.509 è la 1 per cui ci sono meno campi di quelli descritti prima per la versione 3):
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 2 (0x2)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=IT, ST=, L=Bologna, O=Trustix srl,
CN=Trustix s.r.l./Email=certificati@trustix.it
Validity
Not Before: Jul 15 18:39:55 2001 GMT
Not After : Jul 15 18:39:55 2002 GMT
Subject: C=IT, ST=, L=Bologna, O=Umberto Salsi,
CN=Umberto Salsi/Email=salsi@icosaedro.it
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:e8:d3:b6:06:09:3b:5a:cb:d1:ad:db:e6:a4:0f:
74:58:bb:71:2e:06:2a:3b:87:c4:fb:8e:0a:0f:09:
47:d0:ca:83:24:0d:2f:90:76:95:7e:b9:c8:36:28:
31:39:da:84:32:3f:19:5b:a4:d0:4a:2d:26:76:51:
49:93:0d:76:be:f7:e2:e1:45:29:8f:80:02:63:ce:
3a:db:8c:bb:f4:bf:ce:b9:c0:68:85:ed:16:7f:54:
ba:dc:df:e3:34:57:09:28:0e:bd:62:e0:eb:a8:1b:
a4:8b:7e:79:7b:94:e5:f2:6a:bd:02:07:32:57:78:
f4:9f:13:b0:22:03:38:be:73
Exponent: 65537 (0x10001)
Signature Algorithm: md5WithRSAEncryption
91:0d:f4:db:1b:c8:3b:ba:46:f4:e7:11:ac:13:07:17:72:79:
8a:cf:31:86:e1:28:40:65:cd:b8:f7:88:3b:dd:31:4d:78:be:
1a:fb:b5:41:6e:04:ab:db:19:7e:f3:a6:1b:80:b8:59:8a:9a:
b2:7b:1b:28:5a:5a:00:7b:13:79:86:48:f3:96:bb:0d:06:f2:
32:36:bd:98:d7:fe:03:64:70:fe:04:85:6b:89:fa:ef:02:01:
70:01:cf:3b:97:86:82:7d:65:9b:e9:1f:0f:78:46:06:9d:4d:
72:ec:c9:99:49:11:11:12:0d:b4:29:8b:35:63:92:41:34:a8:
f5:c5
-----BEGIN CERTIFICATE-----
MIICZjCCAc8CAQIwDQYJKoZIhvcNAQEEBQAwejELMAkGA1UEBhMCaXQxDjAMBgNV
BAgTBUl0YWx5MRAwDgYDVQQHEwdCb2xvZ25hMRMwEQYDVQQKEwpDYXN0b3Jpbm94
MRYwFAYDVQQDEw1VbWJlcnRViFNhbHNpMRwwGgYJKoZIhvcNAQkBFg1zYWxzaUBj
YXN0b3JvMB4XDTAxMDcxNTE4Mzk1NVoXDTAyMDcxNTE4Mzk1NVowfTELMAkGA1UE
BhMCaXQxDjAMBgNVBAgTBUl0YWx5MRAwDgYDVQQHEwdCb2xvZ25hMRQwEgYDVQQK
EwtQcm92ZXR0aW5veDEWMbqGA1UEAxMNVW1iZXJ0byBTYWxzaTEeMBwGCSqGSIb3
DQEJARYPc2Fsc2lAbG9jYWxob3N0MIGfMA0GCSqGSIb3DQEBAQUaa4gNADCBiQKB
gQDo07YGCTtay9Gt2+akD3RYu3EuBio7h8T7jgoPCUfQyoMkDS+QdpV+ucg2KDE5
2oQyPxlbpNBKLSZ2UUmTDXa+9+LhRSmPgAJjzjrbjLv0v865wGiF7RZ/VLrc3+M0
VwkoDr1i4OuoG6SLfnl7lOXyar0CBzJXePSfE7AiAzi+cwIDAQABMA0GCSqGSIb3
DQEBBAUAA4GBAJEN9NsbyDu6RvTnEawTBxdyeYrPMYbhKEBlzbj3iDvdMU14vhr7
tUFuBKvbGX7zphuAuFmKmrJ7GyhaWgB7E3mgsPOWuw0G8jI2vZjX/gNkcP4EhWuJ
+u8CAXABzzuXhoJ9ZZvpHw94RgadTXLsyZlJERESDbQpizVjkkE0qPXF
-----END CERTIFICATE-----
Ad esempio, il pacchetto OpenSSL (www.openssl.org) oltre
ad implementare il protocollo SSL, contiene anche un programma per
la generazione dei messaggi X.509. Ecco in sintesi come generare un
certificato server.crt per il proprio server. Per prima
cosa, si crea la chiave segreta server.key:
$ openssl genrsa -des3 -out server.key 1024
poi si crea la richiesta di registrazione server.csr da inviare
all'autorità di certificazione, richiesta che contiene i dati necessari
nel formato X.509 e la firma digitale della richiesta fatta con la mia chiave
segreta appena creata:
$ openssl req -new -days 365 -key server.key -out server.csr
La richiesta, così come generata nel file, viene inoltrata alla CA,
la quale, una volta completato l'iter di certificazione, ritornerà
un certificato simile a quello che ho mostrato nell'esempio. Questo
certificato permetterà ai client che si collegano al nostro
server di ottenere l'identità del server certificata con firma
digitale dalla CA scelta. I siti WEB che fanno uso del protocollo
SSL e che permettono di accertare l'identità del sito stesso,
hanno un URL che comincia con https:// al posto del solito
http://. A loro volta anche gli utilizzatori di browser
possono inserire nel browser un certificato personale attraverso il
quale il server può accertare l'identità del navigante.
Il modello per la certificazione delle chiavi proposto dall'X.509 è molto diverso e incompatibile dal modello del Web-of-trust di OpenPGP. Nel caso dell'X.509 c'è una gerarchia di CA che fanno capo a poche autorità principali. Le CA autorizzate possono, a loro volta, delegare altre CA il ruolo di certificazione. La morale, in definitiva, è che nel modello X.509 ogni chiave pubblica deve essere certificata da una CA, e le varie CA assumono una struttura ad albero.
Per l'Italia l'AIPA (www.aipa.it)
mantiene l'elenco ufficiale delle CA autorizzate che, al momento in cui
scrivo (febbraio 2002) risultano essere 13. Occorre contattare la CA
scelta, fornire i dati richiesti, e pagare il servizio. La CA invierà
il kit costituito dalla smart card a processore, l'apposito lettore,
il software per il proprio computer e le istruzioni relative. Vedere anche
la sezione successiva dedicata agli aspetti giuridici per l'esito di tutta
l'operazione svolta da un comune cittadino.
A livello mondiale ci sono diverse ditte che registrano chiavi X.509. Oltre alla famosissima VeriSign, ci sono Thawte, ValiCert, AddTrust, GlobalSign, ecc. Una ricerca in Internet porta rapidamente a trovare un buon numero di CA distribuite nel territorio. Naturalmente, non si tratta di CA riconosciute dalle normative italiane correnti, ma forse potranno esserlo per le future normative europee.
Sebbene i due modelli per la validazione delle chiavi pubbliche sfruttino le stesse tecnologie crittografiche, essi sono formalmente e operativamente completamente diversi e incompatibili. Vediamo in questa tabella alcuni criteri di confronto (le valutazioni qui espresse sono esclusivamente mie ed hanno un valore puramente indicativo):
| Web-of-trust | X.509 | |
|---|---|---|
| Struttura | Distribuita. | Gerarchica. |
| Costo di struttura | Nessuno. | Richiede la creazione delle CA. |
| Costo di registrazione | Nessuno. | E' richiesta la certificazione e la custodia della chiave. |
| Altri costi per l'utilizzatore | Sono disponibili sia programmi gratuiti che programmi a pagamento. Non sono richiesti particolari dispositivi hardware. | Alcune implementazioni commerciali già disponibili, ma probabilmente non definitive. In attesa di normative precise al riguardo prima della diffusione di massa. |
| Fiducia nella validità delle chiavi | Scarsa o nulla; occorrono controlli incrociati a carico dell'utilizzatore. | Generalmente elevata, ma dipendente dai controlli effettivamente svolti dalla CA; non possibili i controlli incrociati (tipicamente l'utilizzatore registra la propria chiave pubblica presso una sola CA). |
| Praticità d'uso | Richiede forte intervento umano di controllo. | Totalmente automatico. |
| Destinazione d'uso tipica | Singoli individui, professionisti, basso numero di chiavi da gestire. | Ambienti di lavoro, implementazioni totalmente automatizzate, grande numero di chiavi da gestire. Adottato dall'AIPA nel suo progetto originario, e probabilmente sarà adottato dalle future leggi europee in materia di crittografia e firma digitale. |
| Validità legale | Le normative emanate dall'AIPA non riconoscono alcuna particolare validità alla firma digitale PGP. La normativa europea 1999/93/CE, attualmente in fase di recepimento da parte del nostro paese, potrebbe cambiare le cose. Vedere la sezione sugli aspetti giuridici per maggiori dettagli. | In attesa di normative dettagliate. Una volta approvato, il sistema avrà validità legale a tutti gli effetti ai fini della firma digitale e altre funzionalità. In alcuni casi, come previsto da recenti leggi italiane in corso di attuazione, le tecniche crittografiche saranno l'unico strumento ammesso per interfacciarsi con la PA nel disbrigo di certe pratiche. |
I documenti RFC, che costituiscono la documentazione ufficiale di Internet,
sono reperibili in
www.rfc-editor.org.
www.rsasecurity.com).
| Umberto Salsi | Commenti | Contatto | Mappa | Home / Indice sezione |
Still no comments to this page. Use the Comments link above to add your contribute.