Un key signing party è una riunione di persone che usano il sistema di
crittografia PGP, durante la quale ogni partecipante ha la possibilità di
firmare la chiave degli altri. I key signing party aiutano in modo consistente
a estendere la propria rete della fiducia, inoltre offrono un'opportunità per
discutere di questioni sociali e politiche che riguardano la crittografia
forte, la sovranità e le libertà individuali, dell'implementazione di
tecnologie crittografiche, o perfino degli sviluppi futuri del software libero
per la crittografia.
1.2 Cosa significa firmare una chiave?
Firmare una chiave significa apporre una firma digitale su una chiave pubblica e sul pacchetto userid che la accompagna. La firma delle chiavi serve per verificare che un dato user id e una data chiave pubblica appartengano veramente alla persona che sembra possedere la chiave e che è indicata nel pacchetto user id.
È possibile firmare la propria chiave pubblica e uno user id associato a quella chiave, oppure la coppia chiave - user id di un'altra persona.
In un certo senso le firme convalidano le chiavi. Rappresentano una dichiarazione di approvazione della validità di una chiave pubblica e dell'id associato, ad opera di una terza parte. In questo senso la firma delle chiavi aiuta a costruire la rete della fiducia.
1.3 Cos'è la rete della fiducia?
La rete della fiducia è un termine usato per descrivere le relazioni di fiducia esistenti tra un gruppo di chiavi. La firma su una chiave rappresenta un collegamento, o un filo se volete, nella rete della fiducia. Questi collegamenti sono chiamati percorsi di fiducia e possono essere bidirezionali o a senso unico. La rete della fiducia ideale è quella in cui ogni persona è connessa ad ogni altra in modo bidirezionale, così che ognuno abbia la fiducia che ogni chiave appartenga veramente al proprio proprietario. La rete della fiducia può essere pensata come la somma dei percorsi di fiducia, o collegamenti, tra tutti i proprietari delle chiavi. Per vedere un esempio visuale, ecco il grafico di una rete di fiducia a cui appartengo.
1.4 Puoi farmi un esempio di applicazione della firma delle chiavi?
Per esempio, poniamo che Alice e Bob creino delle chiavi PGP con GPG e organizzino un key signing party. Durante il party, Alice e Bob verificano ognuno le chiavi dell'altro e successivamente le firmano. Poiché GPG firma automaticamente le chiavi pubbliche che genera usando la chiave privata associata, Alice e Bob avranno almeno due firme che indicano che la chiave appartiene veramente a loro: la chiave di Alice è stata firmata da Alice stessa e da Bob, così pure per la chiave di Bob. In seguito Alice e Bob conoscono Cathy, che genera un paio di chiavi e spedisce la propria chiave pubblica ad Alice e Bob. Alice però non vuole che Bob comunichi con Cathy in modo cifrato, così crea una chiave con il nome di Cathy e la spedisce a Bob. Bob riceve così due chiavi che portano entrambe il nome di Cathy e la firma della chiave privata di Cathy, ma non sa quale delle due è veramente la chiave di Cathy. Cathy scopre che Bob ha ricevuto due chiavi, sospetta subito di Alice e decide di vendicarsi; per farlo, manda a Bob una finta e-mail a nome di Alice comunicandogli di aver generato una nuova coppia di chiavi e includendo la "nuova" chiave di Alice (che in realtà è una falsa chiave generata da Cathy). Ma Bob scopre subito che si tratta di un trucco, visto che una delle due chiavi di Alice che possiede è stata firmata da più persone (Alice e Bob), confermando che essa appartiene davvero ad Alice, mentre l'altra chiave (la falsa chiave creata da Cathy) ha solo una firma.
Questo esempio è molto semplice, ma possono esistere situazioni molto più complicate: potete leggere le FAQ di PGP o un buon libro sulle PKI (Public Key Infrastructure) per maggiori informazioni e spiegazioni più dettagliate. L'esempio mostra comunque i concetti base della firma delle chiavi e la sua importanza: Cathy non è riuscita a introdurre una falsa chiave di Alice, grazie alle interconnessioni esistenti tra Bob e Alice nella loro rete della fiducia.
Tuttavia, firme e reti della fiducia non garantiscono chiavi di cui ci si possa fidare ciecamente. Ad esempio, supponiamo che quando Bob e Alice hanno conosciuto Cathy fosse presente anche Donald, un amico di Cathy. Donald potrebbe aver generato una coppia di false chiavi di Alice e Bob, potrebbe aver firmato ognuna delle due chiavi con quella dell'altro, oltre che con la propria chiave, in modo che ogni chiave contenesse tre firme, e potrebbe aver spedito le chiavi a Cathy. Cathy ora si troverebbe di fronte un gruppo di chiavi e di firme tutte "false": come potrebbe usare il meccanismo della firma per proteggersi da questo tipo di attacchi? Supponiamo che tutte le persone coinvolte scambino le chiavi attraverso un keyserver. Se Cathy cercasse le chiavi di Alice e Bob sul keyserver, troverebbe due paia di chiavi per Alice e Bob, ma se Alice e Bob avessero raccolto venti firme durante un key signing party, è ovvio che Cathy si fiderebbe di più delle chiavi firmate venti volte, piuttosto che di quelle firmate solo tre volte. Inoltre, Cathy potrebbe ricavare altre informazioni riguardanti le venti chiavi usate per le firme, ad esempio le loro date di generazione, ricostruendo così la rete di fiducia che lega le chiavi. Probabilmente le chiavi usate per apporre le firme durante il party saranno state a loro volta firmate con altre chiavi, quasi sicuramente avranno date di generazione molto diverse. Di certo non sarebbe così se Donald avesse generato venti false chiavi e le avesse usate per creare una falsa rete della fiducia.
1.5 Perché dovrei organizzare un key signing party?
Ci sono tre motivi principali per organizzare quanti più key signing party possibili.
Il primo motivo, forse il più importante, per cui dovreste organizzare quanti più key signing party possibili è per espandere la rete della fiducia: più questa diventa profonda e interconnessa, più risulta difficile comprometterla. Questo è molto importante per la comunità del software libero, sia per gli sviluppatori che per gli utenti. I membri della comunità usano la tecnologia PGP per proteggere crittograficamente i loro pacchetti software, gli annunci, i comunicati riguardanti la sicurezza. La forza e la protezione che PGP fornisce alla comunità sono direttamente proporzionali alla forza e la robustezza della rete della fiducia.
In secondo luogo, i key signing party aiutano ad acquisire una cultura della sicurezza e una conoscenza del funzionamento di PGP e delle altre tecnologie per la crittografia forte. Per sfruttare i benefici della crittografia forte, occorre usarla, e usarla nel modo corretto.
Infine, i key signing party aiutano a costruire comunità. Aiutano i tecnici a conoscersi meglio, a lavorare in rete e discutere di importanti questioni riguardanti i diritti civili, il diritto alla crittografia e i meccanismi di regolamentazione di internet. La discussione è importante, non solo perché rappresenta il primo passo, ma anche perché è il passo che precede l'azione. Al momento della scrittura di questo documento non esistono molte reti della fiducia complesse al mondo; se volete costruire una rete della fiducia nella vostra zona, è molto probabile che i primi a farne parte saranno i leader della comunità internet della vostra zona: sono le persone che hanno l'autorità di introdurre tecnologie di crittografia forte nelle infrastrutture che gestiscono, se decidono di farlo. L'introduzione di queste tecnologie e protocolli renderebbe tecnologicamente impossibili cose come il sistema carnivore dell'FBI.
Non è troppo difficile organizzare e coordinare un key signing party, ma, oltre alle usuali operazioni di invitare le persone, trovare un posto e decidere un orario, il coordinatore ha alcune altre responsabilità specifiche, connesse alla firma delle chiavi; tipicamente: fornire una lista delle chiavi ad ogni partecipante e decidere la struttura del key signing party.
2.2 Come va strutturato il party?
Ci sono due modi principali in cui può essere strutturato un key signing party: in modo centralizzato o decentralizzato. L'approccio migliore dipende dal numero di partecipanti e dall'atmosfera del luogo dove si terrà il key signing party. I requisiti di base per il party sono due: i partecipanti devono essere in grado di verificare le chiavi e le identità degli altri partecipanti. Soddisfatti questi due requisiti, il coordinatore può introdurre anche qualche variante ai due modi.
Un party centralizzato necessita di maggiore organizzazione e funziona bene con un numero di persone medio-piccolo. I partecipanti spediscono le informazioni sulle proprie chiavi al coordinatore, che le riunisce in una lista, consegnata ad ogni partecipante al suo arrivo al party. Ogni partecipante viene poi chiamato dal coordinatore a controllare che l'impronta digitale della propria chiave corrisponda a quella scritta sulla lista che il coordinatore ha distribuito. Se il partecipante è sicuro che la propria chiave sia la stessa riportata sulla lista, allora leggerà l'impronta digitale ad alta voce, in modo che gli altri partecipanti possano controllare di avere esattamente questa impronta digitale sulla propria lista, apponendovi un segno in caso di verifica positiva. Questo passo è necessario per assicurarsi che il coordinatore non abbia fatto un errore nella stampa della lista, o che non abbia alterato le informazioni relative a uno o più partecipanti. Dopo che ognuno ha controllato la chiave del primo partecipante, il coordinatore chiama il partecipante successivo, e così via. Dopo aver così controllato tutte le chiavi, i partecipanti e il coordinatore devono formare una lunga fila tenendo un proprio documento di identificazione ben visibile. La persona all'inizio della fila, inizia a scorrere lungo di essa per controllare l'identità degli altri partecipanti. Una volta verificata l'identità di un partecipante, se sulla lista c'è già un segno accanto al suo nome (ossia si è verificato all'inizio del party che la chiave sulla lista è proprio la sua) si pone un secondo segno accanto al nome del partecipante. Quando una chiave ha due segni di verifica, può essere firmata.
In un party decentralizzato, in pratica ognuno fa da sè. I partecipanti si incontrano informalmente cercando altri partecipanti a cui non hanno ancora firmato la chiave. Dopo essersi incontrati, verificano le rispettive chiavi e convalidano le rispettive identità. I party decentralizzati permettono di coinvolgere molte più persone, ma si corre il rischio che non tutti i partecipanti convalidino le rispettive chiavi per poi firmarle. In un party decentralizzato, è importante che il coordinatore incoraggi ognuno ad assicurarsi di aver incontrato tutti gli altri partecipanti per la convalida delle chiavi. Anche se per un party decentralizzato una lista delle chiavi e delle impronte digitali non è necessaria, può comunque tornare utile.
I party centralizzati sono particolarmente adatti da svolgere durante conferenze, pranzi, riunioni informali e tranquille a casa di qualcuno o al ristorante, ecc. I party decentralizzati sono molto più adatti in situazioni che coinvolgono un grande numero di persone, che si svolgono in un bar o in altri posti rumorosi, o che vedono tra i partecipanti dei geek particolarmente disordinati o difficili da controllare.
Più grande è il party, meglio è. Potete annunciare il party sulla mailing list del LUG locale, o su altre liste dedicate all'informatica, o anche con un annuncio sui giornali o una conferenza stampa.
Se state appena iniziando a costruire la rete della fiducia nella vostra zona, è una buona idea cercare di coinvolgere altri utenti attivi di PGP, visto che sono tra quelli che più probabilmente organizzeranno altri key signing party in futuro. Un buon modo per rintracciarli è chiedere a chi spedisce messaggi con firme PGP sulle liste a cui partecipate, o cercare sulle reti di keyserver chiavi con indirizzi mail tipici della vostra zona, ad esempio indirizzi mail con nomi di dominio di un'università o di una grande impresa della vostra zona.
Ecco alcuni esempi di annuncio [gli esempi sono in lingua inglese; per un esempio di organizzazione di un key signing party in Italia, cfr http://www.mksp.m4d.sm, NdT]:
2.4 Generare le liste delle chiavi
Se pensate di organizzare un party che richiede una lista delle chiavi dei partecipanti, il coordinatore deve generare la lista in un formato simile a questo:
| Key ID | Proprietario | Impronta digitale | Dimensione della chiave | Tipo di chiave | Controllo informazioni della chiave | Controllo identità del proprietario |
| 992A4B3F | V. Alex Brennen < vab@cryptnet.net > | 0EC8 B0E3 052D FC4C 208F 76EB FA92 0973 992A 4B3F | 1024 | DSA |
Ho scritto uno script perl che genera un documento HTML con la struttura della tabella qui sopra a partire da un portachiavi gpg. Lo script perl per generare una lista di chiavi per un key signing party è disponibile sotto i termini della GNU General Public License (GPL).
Occorre poi stampare una copia della lista per ognuno dei partecipanti al key signing party; il coordinatore potrà stampare le copie della lista, o spedirla per e-mail, o metterla a disposizione sul web, in modo che i partecipanti la stampino.
2.5 Rappresentare graficamente la rete della fiducia
Niente attira l'interesse delle persone come un grafico colorato. Rappresentare graficamente la rete della fiducia che state costruendo nella vostra zona può aiutare a motivare le persone a partecipare; inoltre può dare a ognuno una visione chiara dei risultati raggiunti man mano che le cose progrediscono.
Potete creare facilmente un grafico di tutte le chiavi e le firme della vostra rete della fiducia convertendo queste informazioni in un dot file, che può essere poi elaborato con un programma per creare grafici, come dot o neato. Uno script perl che converte le chiavi e le firme di un portachiavi in un file in formato dot è stato scritto da Darxus ed è disponibile sotto i termini della GPL. Per rappresentare graficamente la vostra rete della fiducia, dovete scaricare lo script sig2dot.pl di Darxus e il pacchetto graphviz della AT&T Research. Se la vostra rete della fiducia contiene più di qualche centinaio di nodi, potreste non essere in grado di visualizzarla a causa della memoria richiesta per l'operazione.
Istruzioni per rappresentare la rete della fiducia di un portachiavi gpg si trovano nello script sig2dot.pl, o sulla "Debian keyring graphing page". Ecco un link per vedere un grafico di una rete della fiducia prodotto con lo script sig2dot.pl e il programma grafico neato. Maggiori informazioni sono disponibili sulla Debian keyring graphing page.
Non occorre portare un computer al party perché è molto facile compromettere un sistema PGP sostituiendo un programma o facendo modifiche al sistema operativo.
Se i partecipanti usassero un computer portato da qualcuno per firmare le altre chiavi, nessuno saprebbe se sul computer c'è un programma che registra i tasti premuti, o una versione modificata di GPG o del kernel Linux, o una tastiera modificata in modo speciale, tutti modi che possono essere usati per catturare la chiave privata delle persone che hanno usato il computer.
Usare un computer al party vi renderebbe anche vulnerabili ad attacchi semplici, come lo spiare da dietro le spalle, o complessi, come la generazione di chiavi private deboli, la modifica di chiavi private, o perfino l'infezione con virus che modificano gli eseguibili di GPG in modo da catturare silenziosamente le chiavi private.
3.5 Generare un paio di chiavi
La procedura per generare un paio di chiavi è abbastanza semplice. In
pratica dovete eseguire gpg --gen-key. In ogni caso, è
raccomandabile generare anche un certificato di revoca per la propria chiave,
nel caso si perdesse l'accesso alla propria chiave privata (ad es. se si
dimentica la passphrase o si perde la chiave privata). Le istruzioni per
generare un certificato di revoca si trovano nel capitolo 3.7 di questo documento.
Qui sotto trovate istruzioni passo-passo, scritte tenendo in mente la praticità di utilizzo e un livello sufficiente di sicurezza:
Alcuni potrebbero sentirsi a proprio agio anche senza adottare queste precauzioni di sicurezza. Ad esempio, se avete un computer portatile o desktop su cui leggete tutta la vostra posta, potete salvare la vostra chiave sul disco rigido di quel computer. Potete anche generare un paio di chiavi senza scadenza da usare per identificarvi e per la maggior parte delle comunicazioni, e generare altre paia di chiavi per le comunicazioni estremamente delicate (se doveste averne). Le istruzioni passo-passo riportate qui sotto, invece, tengono conto delle migliori precauzioni di sicurezza. Non dovete necessariamente seguirle, visto che tutto quello di cui avete bisogno è un paio di chiavi, ma se siete un paranoico ossessionato dalla sicurezza come me, seguire le istruzioni qui sotto vi procurerà quel temporaneo e fuggevole senso di calma di cui avete così bisogno.
Le istruzioni qui sotto sono scritte tenendo in mente le migliori pratiche di sicurezza, ad esempio:
1) Andate su www.gnupg.org e scaricate l'ultima versione di gnupg: gnupg-x.x.x.tar.gz
Attenzione: assicuratevi di usare almeno la versione 1.0.6 di GnuPG. Le versioni precedenti alla 1.0.6 avevano almeno un problema di sicurezza significativo [al momento della traduzione italiana di questo documento, l'ultima versione di GnuPG consigliata è la 1.2.3, cui si riferiscono anche i messaggi riportati in seguito, NdT].
2) Controllate le firme PGP e il Checksum MD5 sull'archivio GnuPG:
bash$ gpg --verify gnupg-x.x.x.tar.gz.sig gnupg-x.x.x.tar.gz
bash$ md5sum gnupg-x.x.x.tar.gz
3) Estraete l'archivio, configurate, compilate e installate:
bash$ tar xvzf gnupg-x.x.x.tar.gz
bash$ cd gnupg-x.x.x
bash$ ./configure
bash$ make
bash$ su
bash# make install
bash# exit
bash$ cd
Se condividete con altri il sistema su cui state installando GnuPG, probabilmente vorrete rendere gpg setuid root, in modo da usare memoria sicura. Se scegliete di fare questo, per precauzione controllate sempre l'archivio con la firma md5 e la firma pgp per essere sicuri di non installare un cavallo di Troia.
4) Prendete un floppy su cui conservare le chiavi e formattatelo:
bash$ /sbin/mkfs.ext2 /dev/fd0
4a) Montate il floppy e create una directory posseduta da voi, per le
vostre chiavi:
bash$ mount /mnt/floppy
bash$ mkdir /mnt/floppy/.gnupg
e se è necessario (dipende da come è regolato sul vostro sistema l'accesso a fd0):
bash$ chown <vostro_uid>:<vostro_gid> /mnt/floppy/.gnupg
4b) Create un link simbolico dalla vostra directory home al floppy:
bash$ ln -s /mnt/floppy/.gnupg .gnupg
5) Generate le vostre chiavi gnupg:
bash$ gpg --gen-key
5a) Selezionate i tipi di chiave che volete (le scelte predefinite vanno
bene).
Per favore scegli che tipo di chiave vuoi:
(1) DSA e ElGamal (default)
(2) DSA (firma solo)
(5) RSA (firma solo)
Cosa scegli? <invio>
5b) Selezionate la dimensione della vostra chiave: 2048
La coppia DSA avrà 1024 bit.
Sto per generare una nuova coppia di chiavi ELG-E.
la dimensione minima è 768 bit
la dimensione predefinita è 1024 bit
la dimensione massima consigliata è 2048 bit
Di che dimensioni vuoi la chiave? (1024) 2048<invio>
5c) Scegliete la durata di questa chiave: 5 anni va bene.
La dimensione richiesta della chiave è 2048 bit
Per favore specifica per quanto tempo la chiave sarà valida.
0 = la chiave non scadrà
<n> = la chiave scadrà dopo n giorni
<n>w = la chiave scadrà dopo n settimane
<n>m = la chiave scadrà dopo n mesi
<n>y = la chiave scadrà dopo n anni
Chiave valida per? (0) 5y<invio>
La chiave scadrà il Sun Sep 21 16:17:15 2005 EDT
È giusto (s/n)? s<invio>
5d) Inserite il vostro nome e il vostro indirizzo e-mail:
Nome e Cognome: Utente Di Prova<invio>
Indirizzo di Email: prova@non.esiste<invio>
Commento:
Hai selezionato questo User Id:
"Utente di Prova <prova@non.esiste>"
Modifica (N)ome, (C)ommento, (E)mail oppure (O)kay/(Q)uit? O<invio>
5e) Scegliete una passphrase. Dovete sceglierla bene: dev'essere lunga e molto difficile da indovinare, ma anche da dimenticare. Se dimenticate la passphrase, non potrete recuperare la vostra chiave.
5f) Muovete il mouse e premete qualche tasto, o eseguite in background un comando come updatedb o find. GPG leggerà /dev/random per raccogliere dei numeri casuali necessari per generare le chiavi, e /dev/random è popolato in parte anche dagli interrupt.
6) Modificate la vostra chiave, se volete. Ad esempio, se avete più di un
indirizzo e-mail e volete che compaiano tutti sulla vostra chiave:
bash$ gpg --list-secret-keys
/home/utente/.gnupg/secring.gpg
----------------------------
sec 1024D/C01BAFC3 2000-09-21 Utente di Prova <prova@non.esiste>
ssb 2048g/7A4087F3 2000-09-21
bash$ gpg --edit-key C01BAFC3
Comando> help
Comando> adduid
[...]
Comando> save
7) Spedite la vostra chiave pubblica al keyserver:
[vab@firster vab]$ gpg --keyserver <keyserver> --send-key <Vostro_Key_ID>
Dovreste ottenere un messaggio di successo simile a questo:
gpg: inviata con successo a `<keyserver>' (status=200)
3.6 Spedire la chiave pubblica a un keyserver
Nota importante: alcuni pensano che tenere segreta la propria chiave pubblica aggiunga ulteriore sicurezza alle proprie comunicazioni cifrate. Questo è vero, nel senso che un keyserver potrebbe essere difettoso o potrebbe venir compromesso e restituire chiavi pubbliche sbagliate. Inoltre, la chiave disponibile su un keyserver potrebbe non essere la più aggiornata disponibile: ad esempio, potrebbero essere state aggiunte delle firme alla chiave che non sono state caricate sul keyserver. È anche vero che la chiave pubblica può essere usata per certi tipi di attacco ai sistemi di crittografia pubblica, e anche se molti pensano che questi tipi di attacco siano estremamente improbabili nel caso venga usata una chiave di dimensione abbastanza grande, tenere segreta la chiave pubblica di fatto riduce questa possibilità.
Tuttavia, non vi consiglio di tenere segreta la vostra chiave pubblica, visto che scoraggerebbe gli altri dall'usare PGP per le loro comunicazioni con voi. Per risolvere il problema di un possibile keyserver difettoso o compromesso che restituisce le chiavi sbagliate, potete evitare di ricevere messaggi cifrati con la chiave sbagliata ad esempio pubblicando l'impronta digitale della vostra chiave nel vostro file .signature o sulla vostra pagina web. Per quanto riguarda il problema del possibile attacco alla vostra chiave privata attraverso la conoscenza della vostra chiave pubblica, se siete davvero così preoccupati per la robustezza delle vostre chiavi o per la segretezza delle vostre comunicazioni, potete generare ulteriori paia di chiavi (che scadano entro qualche ora o qualche giorno) per ogni comunicazione e scambiare le chiavi pubbliche attraverso canali cifrati con la persona con cui dovete comunicare.
Se non volete che la vostra chiave sia pubblicata su un keyserver, non seguite questo passo della procedura, e invece spedite la vostra chiave pubblica al coordinatore del key signing party, indicandogli che non volete che la vostra chiave sia pubblicata su un keyserver. Il coordinatore potrà quindi estrarre le informazioni della vostra chiave pubblica e inoltrare la chiave agli altri partecipanti attraverso posta elettronica cifrata, o qualche altro metodo, insieme a un messaggio che indica che la chiave, una volta firmata, va rispedita al proprietario, ma non caricata su un keyserver.
3.7 Generare un certificato di revoca
Questo è un passo opzionale.
Generare e conservare un certificato di revoca vi permetterà di revocare la vostra chiave pubblica anche nell'eventualità che non possiate più accedere alla vostra chiave privata, a causa di un furto, di una compromissione, della dimenticanza della passphrase, o di un guasto del supporto. Se volete avere la possibilità di revocare la vostra chiave pubblica senza avere accesso alla chiave privata, dovete generare un certificato di revoca e conservarlo in un posto sicuro. Dovreste anche stampare una copia del vostro certificato di revoca in modo da poterlo riscrivere e usare in caso di guasto del supporto su cui è registrato.
Se il certificato di revoca viene compromesso, la persona che riesce ad entrarne in possesso sarà in grado di farlo circolare, disabilitando così la vostra chiave pubblica. Tuttavia, non sarà in grado di compromettere la vostra chiave privata e quindi neanche di generare false firme, decifrare messaggi cifrati con la vostra chiave pubblica o presentarsi abusivamente come il proprietario del vostro paio di chiavi. Visto che l'unico rischio connesso alla compromissione di un certificato di revoca consiste nella disabilitazione della vostra chiave pubblica, è abbastanza sicuro e utile generarne uno.
La sezione 3.9 contiene maggiori informazioni a proposito della revoca delle chiavi.
Il comando GnuPG per generare un certificato di revoca è:
bash$ gpg --output certificato_revoca.asc --gen-revoke <key_id>
9) Spedite le vostre informazioni al coordinatore, dicendo che avete
intenzione di partecipare al key signing party. Se la vostra chiave è
disponibile sui keyserver, il comando qui sotto mostrerà tutte le informazioni
che dovete spedire al coordinatore; la spedizione può avvenire ad esempio
tramite un messaggio e-mail cifrato.
bash$ gpg --fingerprint <Vostro_Key_ID>
10) Smontate il floppy ed estraetelo:
bash$ umount /mnt/floppy
Nota: potete portare con voi il floppy per sicurezza, o potete lasciarlo in un posto sicuro, in un cassetto sotto chiave ecc. NON DOVETE lasciare la vostra directory .gnupg, che contiene le vostre chiavi, in un posto accessibile via internet.
11) Andate al party.
3.8 Firmare le chiavi degli altri
Passo 1: Procuratevi una copia della chiave
Di solito userete un keyserver, ma se state firmando una chiave che non è
disponibile su un keyserver, potete semplicemente importare la chiave con
gpg --import.
Se usate un keyserver, il comando seguente scaricherà la chiave dal keyserver
e la importerà nel vostro portachiavi.
bash$ gpg --keyserver <keyserver> --recv-keys <Key_ID>
Se ricevete un errore di lettura, il keyserver può essere sovraccarico; riprovate dopo qualche secondo.
Passo 2: Prendete l'impronta digitale e verificate la chiave
bash$ gpg --fingerprint <Key_ID>
GPG stamperà l'impronta digitale della chiave con l'identificativo <Key_ID > (la chiave che avete appena scaricato). Controllate che l'impronta digitale corrisponda a quella riportata sulla lista che avete ricevuto al party. Nota: non controllate che l'impronta digitale che avete sulla lista corrisponda con quella pubblicata sulla pagina web del keyserver, visto che un keyserver difettoso o compromesso potrebbe non spedirvi la stessa chiave che mostra sulla pagina web.
Passo 3: Firmate la chiave
bash$ gpg --sign-key <Key_ID>
Se avete più di una chiave privata, potete specificare quale delle vostre
chiavi private usare per firmare le chiavi pubbliche degli altri in questo
modo:
bash$ gpg --default-key <Chiave_da_usare> --sign-key <Key_ID>
Se avete problemi con le chiavi RSA, probabilmente state usando una vecchia
versione di gnupg. Le versioni precedenti alla 1.0.3 non includono il supporto
RSA. Nota: potreste dover disinstallare una versione precedente di gnupg se
l'avevate installata tramite il sistema di gestione di pacchetti della vostra
distribuzione. Potete controllare che versione state usando così:
bash$ gpg --version
Passo 4: Rispedite o caricate la chiave firmata
Se la persona con cui avete a che fare non vuole che la sua chiave sia pubblicata su un keyserver, a questo punto dovete rispedirgli la chiave firmata con la modalità che vi avrà indicato (di solito via e-mail cifrata). Non dovreste spedire una chiave pubblica a un keyserver senza il permesso del proprietario. Far circolare la chiave pubblica riduce lievemente la sicurezza di un paio di chiavi, quindi è considerato scortese rendere una chiave più pubblica di quanto il proprietario desideri.
Più probabilmente userete un keyserver. Se è questo il caso, potete
caricare sul keyserver la chiave firmata in questo modo:
bash$ gpg --keyserver <keyserver> --send-key <Key_ID>
Dovreste ottenere un messaggio di successo simile al seguente:
gpg: inviata con successo a `<keyserver>' (status=200)
Congratulazioni, la procedura di firma della chiave è stata completata e la vostra firma è ora incorporata nella chiave pubblica. È stato così creato un nuovo collegamento nella rete della fiducia.
3.9 Revocare la propria chiave
Nel caso sospettiate che la vostra chiave privata sia stata compromessa, dovreste immediatamente revocare la vostra chiave pubblica. La revoca di una chiave avviene aggiungendo un certificato di revoca a una chiave pubblica: la revoca indica che quella chiave non è più valilda (sicura) e non va usata. Una volta aggiunto, un certificato di revoca non può più essere ritirato.
Poiché la vostra chiave pubblica PGP non viene distribuita da una fonte centralizzata ogni volta che viene usata, ma viene fatta circolare liberamente tra le persone, dovete far circolare anche il certificato di revoca nello stesso modo in cui avete distribuito la vostra chiave pubblica. Questo di solito significa caricare il certificato di revoca sulle reti di keyserver. Anche se non avete caricato la vostra chiave pubblica su un keyserver per motivi di sicurezza, potreste comunque voler caricare sul keyserver il certificato di revoca, facendo così un compromesso tra la leggera riduzione della sicurezza risultante dalla pubblicazione della vostra chiave pubblica, e la riduzione della sicurezza risultante dal fatto che qualcuno potrebbe usare la vostra chiave pubblica senza sapere che è stata revocata.
In sintesi, il comando gpg per generare un certificato di revoca è:
bash$ gpg --output certificato_revoca.asc --gen-revoke <key_id>
Se conoscete il motivo o la data della compromissione della vostra chiave e avevate generato un certificato di revoca generico al momento della creazione della chiave, potete comunque generare un nuovo certificato di revoca. Lo standard openPGP infatti permette di specificare il motivo della revoca di una chiave e di includere anche un commento libero in proposito. Far circolare un certificato di revoca con informazioni precise è preferibile, rispetto all'uso di un certificato di revoca generico creato al momento della generazione della chiave.
Key signing party) - Una riunione di persone che usano il sistema di crittografia PGP con lo scopo di permettere ai partecipanti di firmare a vicenda le proprie chiavi. I key signing party servono ad estendere la rete della fiducia.
Chiave (Key) - Uno o più bit di dati usati in un procedimento di cifratura o decifratura.
Chiave privata (Secret Key) - Nella crittografia a chiave pubblica, la chiave, fra quelle che costituiscono un paio di chiavi, che viene tenuta segreta.
Chiave pubblica (Public Key) - Nella crittografia a chiave pubblica, la chiave, fra quelle che costituiscono un paio di chiavi, che viene distribuita.
Impronta digitale della chiave (Key Fingerprint) - Se si tratta di PGP, un valore usato per identificare una chiave, ricavato calcolando un hash della chiave.
Key Server - Un sistema che immagazzina chiavi in un database. Questi server possono essere interrogati per conoscere la chiave pubblica di un destinatario con cui non si è mai entrati in contatto prima.
openPGP - Uno standard aperto che definisce una versione del sistema PGP.
Paio di chiavi (Key Pair) - Nella crittografia a chiave pubblica, un paio di chiavi consiste in una chiave pubblica e una privata, correlate fra loro.
Percorso di fiducia (Trust Path) - La via attraverso cui la fiducia si estende da un individuo a un altro. In PGP è un collegamento di fiducia tra due chiavi pubbliche.
Portachiavi (Keyring) - Una collezione di chiavi. Tipicamente il termine è usato in relazione a PGP, dove un portachiavi consiste in una raccolta di uno o più pacchetti di chiave.
Portachiavi privato (Secret Keyring) - Una collezione di chiavi private. Il termine è usato tipicamente in relazione a PGP, dove indica una collezione di pacchetti di chiavi private.
Portachiavi pubblico (Public Keyring) - Un portachiavi che raccoglie chiavi pubbliche. Il termine è usato tipicamente in relazione a PGP.
Pretty Good Privacy - PGP - Programma per la privacy sviluppato da Phil Zimmermann, che include la crittografia a chiave pubblica, un formato standard di chiavi e di pacchetti, e anche la crittografia simmetrica.
Radix - Un metodo di codificare i dati in modo che possano essere trasmessi su un canale che supporta solo caratteri a 7 bit (ad esempio, l'e-mail o Usenet).
Rete della fiducia (Web of Trust) - La collezione di firme sulle chiavi e dei risultanti percorsi di fiducia in un modello di fiducia incentrato sull'utente, che garantisce l'autenticazione. In senso collettivo, le relazioni di fiducia in un gruppo di chiavi.
5.1 Lista di keyserver pubblici
5.2 Link a documenti correlati
5.6 Immagini di key signing party
Copyright (c) 2000 - 2003 V. Alex Brennen.
È garantito il permesso di copiare, distribuire e/o modificare questo documento sotto i termini della GNU Free Documentation License, Versione 1.1 o ogni versione successiva pubblicata dalla Free Software Foundation.
Questo documento vive su http://www.cryptnet.net/fdp/crypto/gpg-party.html (versione originale)
Versione 1.0.0, 2000.10.01 Prima pubblicazione.
Versione 1.0.1, 2000.10.03 Modifiche di contenuto e formato, informazioni su chiavi pubbliche e private.
Versione 1.0.2, 2000.12.07 Correzione di un link HTML.
Versione 1.0.3, 2001.01.14 Semplificazione, rappresentazione grafica, informazioni sull'etichetta/sicurezza dei keyserver, codice perl, esempi di annuncio, materiale aggiuntivo e correzioni generali.
Versione 1.0.4, 2001.06.21 Aggiunte informazioni sulla revoca: 3.5, 3.7. Aggiunte informazioni sulle RFC: 4.4. Aggiornate liste di keyserver e siti web.
Versione 1.0.5, 2003.03.24 Aggiunto glossario: 4. Aggiunte immagini: 5.5. Correzioni minori, materiale aggiuntivo e modifiche di formato.
Versione 1.0.6, 2003.03.24 Nuovo contenuto: metodo Zimmermann-Sassaman, metodo Brennen. Ripulitura generale del documento.
Versione 1.0.7, 2003.05.07 Aggiunta traduzione tedesca
Versione 1.0.8, 2003.05.09 Aggiunta sezione 5.3 Programmi correlati
Questo documento al momento è disponibile nelle lingue seguenti:
[en] Inglese
[de]Tedesco (Mirror locale)
[si] Sloveno (Mirror locale)
[it] Italiano
Se siete a conoscenza di una traduzione o volete tradurre il documento in un'altra lingua, fatemelo sapere, in modo che possa distribuirlo o mettere un link alle versioni tradotte.
V. Alex Brennen (autore principale)
Darxus (codice per rappresentazione grafica (sig2dot.pl & sigtrace.pl))
Bostjan Muller (traduzione slovena)
Gerfried Fuchs (traduzione tedesca)
Cristian Rigamonti (traduzione italiana)
