Gnu Privacy Guard

Introduzione

Quanto segue e' da prendere non come una guida completa sull'utilizzo di GnuPG ma come un riferimento pratico e sintetico. Una guida completa e' possibile trovarla sul sito ufficiale dell'upstream http://www.gnupg.org/(it)/index.html

Di cosa si tratta

GnuPG (GNU Privacy Guard) e' un sistema che permette di firmare e/o cifrare digitalmente i propri file, mail ecc. Utilizzabile su molte piattaforme e sistemi operativi diversi. Lo si usa principalmente da riga di comando, ma anche attraverso diverse interfacce grafiche che ne facilitano l'utilizzo in alcuni casi.

GNU Privacy Guard e' un sistema di cifratura che utilizza una DoppiaChiave. Ovvero, vi sono 2 chiavi diverse ma legate fra di loro, una privata e l'altra pubblica, che vengono create insieme come vedremo di seguito. La chiave pubblica e' quella che servira' alle persone le quali dovranno decriptare e/o autenticare i dati che gli invieremo. La chiave privata invece, dovra' essere custodita gelosamente sui nostri pc e non dovra' essere resa MAI pubblica per nessun motivo.

Creiamo le nostre chiavi

Una volta installato, dovremo per prima cosa generare le nostre chiavi, operazione che si esegue una sola volta. Eseguiremo questa operazione, utilizzando l'utente di sistema che normalmente usiamo, o se lo si preferisce da user root, indicando l'UID dell'utente per il quale vorremo generare la coppia di chiavi.

lugbari@morpheus:~$ gpg --gen-key
gpg (GnuPG) 1.4.3; Copyright (C) 2006 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.

gpg: directory `/home/lugbari/.gnupg' created
gpg: creato un nuovo file di configurazione `/home/lugbari/.gnupg/gpg.conf'
gpg: ATTENZIONE: le opzioni in `/home/lugbari/.gnupg/gpg.conf' 
non sono ancora attive durante questa   esecuzione del programma
gpg: portachiavi `/home/lugbari/.gnupg/secring.gpg' creato
gpg: portachiavi `/home/lugbari/.gnupg/pubring.gpg' creato
Per favore scegli che tipo di chiave vuoi:
(1) DSA and Elgamal (
default
)
(2) DSA (firma solo)
(5) RSA (firma solo)
Cosa scegli?

Ci viene chiesto che tipo di chiave vogliamo utilizzare, la scelta consigliata e' la (1)

DSA keypair will have 1024 bits.
ELG-E keys may be between 1024 and 4096 bits long.
What keysize 
do
 you want? (2048)

quindi la lunghezza della stessa e ci viene consigliato 2048.

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)
Key does not expire at all
Is 
this
 correct? (y/N) y

Si puo' specificare anche la durata della chiave se occorre. Un lasso di tempo dopo del quale la chiave scadra' e non sara' piu' utilizzabile.

You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in 
this
 form:
"
Heinrich Heine (Der Dichter) <heinrichh@********.de>
"

Nome e Cognome:

A questo punto ci verranno richiesti dei dati, come Nome e Cognome, un commento e l'indirizzo mail, per generare un'identificativo utente che permettera' al sistema di riconoscere la chiave.

E' molto importante scegliere una password complessa, difficilmente intuibile e che ci si possa ricordare facilmente, visto che la utilizzeremo frequentemente.

Dobbiamo generare un mucchio di byte casuali. È una buona idea eseguire
qualche altra azione (scrivere sulla tastiera, muovere il mouse, usare i
dischi) durante la generazione dei numeri primi; questo da al generatore di
numeri casuali migliori possibilità di raccogliere abbastanza entropia.
+++++..+++++.++++++++++....++++++++++++++++++++++++++++++.+++++

Non ci sono abbastanza byte casuali disponibili. Per favore fai qualche
altra cosa per dare all'OS la possibilità di raccogliere altra entropia!
(Servono altri 282 byte) |

In questo caso, seguire il consiglio del sistema. Possiamo muovere il mouse (se ne abbiamo uno) o scrivere a casaccio con la tastiera, fino a quando non riprendera' con la generazione delle chiavi.

gpg: /home/lugbari/.gnupg/trustdb.gpg: creato il trustdb
gpg: key 0016A67E marked as ultimately trusted
chiavi pubbliche e segrete create e firmate.

gpg: controllo il trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  
signed
:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
pub   1024D/0016A67E 2006-05-14
Key fingerprint = DB83 7E52 173E 32AB 19A7  B174 ABDD B8B2 0016 A67E
uid                  Giovanni Gentile (NetWalker) <netwalker@********.org>
sub   2048g/06616A40 2006-05-14

Avremo quindi le chiavi appena generate nella directory ~/.gnupg, ed insieme ad esse viene creato il database della fiducia (TrustDB) sulle chiavi contenute nel nostro keyring.

Per una spiegazione del concetto di TrustDB, e delle righe che ne descrivono il contenuto, come quelle che compaiono dopo la generazione e firma delle chiavi generate, si veda la sezione TrustDB.

Iniziamo ad utilizzarle

E' buona norma, genere anche un certificato di revoca, che serve appunto per revocare la chiave in caso di necessita'

e salvare tutto su un floppy o cd, da conservare con molta cura.

Per esportare la nostra chiave PUBBLICA:

E' possibile esportarla in un file di testo con l'opzione -a / --armor e -o

Con l'opzione -a, avremo l'output in un file con codifica ASCII a 7bit.

Sara' cosi' possibile reimportarla con:

Esportare ed importare le chiavi pubbliche serve per poterle scambiare con altre persone. Sara' cosi' possibile scambiarsi documenti firmati e/o cifrati.

Una volta ricevuta la chiave di un nostro corrispondente e quindi importata, il sistema la classifichera' come NON SICURA. Dovremo quindi essere noi a contrassegnarla come tale, firmandola.

Dove lugbari è lo userid della chiave che vogliamo firmare.

gpg --edit-key lugbari
gpg (GnuPG) 1.4.3; Copyright (C) 2006 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.

È disponibile una chiave segreta.
pub  1024D/0016A67E  created: 2006-05-14  expires: mai         usage: SC
trust: ultimate      validity: ultimate
sub  2048g/06616A40  created: 2006-05-14  expires: mai         usage: E
[ultimate] (1). Giovanni Gentile (NetWalker) <netwalker@********.org>

a questo punto, useremo la funzione 'sign', per firmarla

Comando> sign|
"
Giovanni Gentile (NetWalker) <netwalker@********.org>
" was already 
signed
 by key 0016A67E
Nothing to sign with key 0016A67E

Comando> quit

Essendo nostra quella chiave, il sistema dira' che e' gia' firmata. Altrimenti ci chiedera' quale livello di sicurezza attribuire alla stessa.

E' di fondamentale importanze essere sicuri della chiave che si sta firmando. Ecco perche' si organizzano i cosi' detti 'key signing party'. Attraverso i quali e' possibile ricevere la chiave direttamente dalle mani del titolare della stessa.

Un'altro modo per accertarsi che la chiave (magari presa attraverso la rete) sia quella giusta e' il controllo del fingerprint, ovvero l'impronta digitale che ci viene fornita dal proprietario.

Per conoscere il fingerprint della nostra chiave:

gpg --fingerprint 0016A67E
pub   1024D/0016A67E 2006-05-14
Key fingerprint = DB83 7E52 173E 32AB 19A7  B174 ABDD B8B2 0016 A67E
uid                  Giovanni Gentile (NetWalker) <netwalker@********.org>
sub   2048g/06616A40 2006-05-14

E' quindi possibile mettere a disposizione di tutti la propria chiave pubblica, attraverso la rete internet, utilizzando un sever pubblico, come pgpkeys.mit.edu.

Possiamo inviare la chiave sul server, direttamente attraverso gpg:

gpg --keyserver pgp.mit.edu --send-key 0016A67E
gpg: sending key 0016A67E to hkp server pgp.mit.edu

In modo tale da rendere disponibile la chiave, per poi firmarla durante il key signing party.

Al contrario, chi volesse prendere la nostra chiave dovrebbe usare l'opzione --recv-key

e quindi proseguire con la fase di firma/autenticazione della stessa.

Qualche nota sul TrustDB

Il TrustDB è un database che viene mantenuto contestualmente alla nostra installazione personale di GnuPG, il quale contiene le informazioni sulla fiducia che noi attribuiamo alle chiavi presenti nel nostro keyring.

Abbiamo bisogno di questo database per tenere traccia di quello che viene denominato Web of Trust nella terminologia di GnuPG e del suo predecessore PGP.

Infatti per essere sicuri che una chiave sia fidata abbiamo due possibilità:

• firmare personalmente la chiave in questione, essendoci preventivamente assicurati dell'identità della persona titolare;
• affidarci ad un meccanismo di calcolo del livello di fiducia di una chiave, che si basa anche su presupposti soggettivi.

Nel primo caso non c'e' molto da dire, poiché se firmiamo una chiave pubblica utilizzando le nostre credenziali private assumiamo implicitamente che il valore di fiducia di quella chiave sia pieno.

Nel secondo caso invece possiamo fare in modo che sia GnuPG a stabilire per noi se una chiave che preleviamo ad esempio da un keyserver, e di cui non abbiamo mai incontrato il titolare, sia o meno affidabile.

Il meccanismo che GnuPG usa di default per stabilire se una chiave è affidabile è il così detto PGP trust model. Secondo questo modello una chiave appartenente ad un soggetto sconosciuto (cioè non firmata da noi personalmente) è valida se è firmata da una chiave (firmata da noi) in cui noi poniamo fiducia piena (fully trusted) oppure da almeno tre chiavi (firmate da noi) nelle quali noi poniamo una fiducia marginale.

Vediamo di spiegare meglio che cosa si intende per chiave in cui poniamo un certo livello di fiducia. In effetti il livello di fiducia a cui ci riferiamo è riferito al titolare della chiave stessa. Infatti il titolare può a sua volta firmare altre chiavi utilizzando le sue credenziali private, e prima di farlo dovrebbe accertarsi dell'identità del possessore. All'atto pratico però questo potrebbe non avvenire, in quanto le operazioni di firma avvengono nei contesti sociali più disparati, oltre che nei già citati keysigning party.

In mancanza di informazioni (soggettive) sul modo con cui riteniamo che una persona verifichi l'identità degli altri suoi conoscenti, potremmo decidere di non riporre una fiducia totale nelle chiavi firmate da questa persona! In tal caso possiamo attribuire alla sua chiave pubblica un livello di trust marginale oppure negare del tutto la fiducia.

Se d'altra parte sappiamo che il titolare di una chiave che noi abbiamo firmato è una persona coscienziosa, scrupolosa o addirittura paranoica quando si tratta di verificare l'identità dei soggetti di cui firma le chiavi, allora potremmo decidere di assegnare alla sua chiave pubblica un livello di trust pieno, e conseguentemente considerare completamente fidate le chiavi da lui firmate.

Vediamo ora come si fa a visualizzare in pratica il riassunto delle informazioni contenute nel nostro database della fiducia.

Ogni volta che si firma una chiave contenuta nel nostro keyring, GnuPG esegue un controllo ed un aggiornamento del trustdb. Possiamo ripetere questo controllo anche indipendentemente dalle operazioni di firma, ogni qual volta riteniamo che ciò sia necessario, con il seguente comando:

che produce ad esempio un output come il seguente:

user@host:~$ gpg --update-trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  
signed
:   7  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:   7  
signed
:   3  trust: 0-, 0q, 4n, 3m, 0f, 0u
gpg: the next trustdb check will be done on 2007-09-15

Analizziamo l'output del comando:

La prima riga mostra la politica di trust in uso dalla nostra installazione di GnuPG (tale politica è infatti configurabile). Essa afferma, come si è detto, che una chiave contenuta nel keyring è valida se è firmata da almeno 3 chiavi con un livello di trust marginale oppure da almeno una chiave con livello di trust pieno.

La seconda riga descrive la chiave o le chiavi di livello 0, ovvero la chiave di cui noi, possessori delle credenziali private di questo keyring, siamo titolari. Essa afferma in definitiva che nel keyring vi è una sola chiave di livello 0, firmata da 7 chiavi pubbliche di altri utenti, contenute nello stesso keyring. Inoltre, tra tutte le chiavi di livello zero, per 0 di esse non abbiamo ancora assegnato una valutazione del livello di trust (0-), per 0 di esse non si ha idea di quale livello di trust assegnare alla chiave (0q, q="I don't know or won't say"), per 0 chiavi avete negato un qualsiasi tipo di fiducia (0n, n="I do NOT trust"), per 0 chiavi si ha un livello di trust marginale (0m, m="I trust marginally"), per 0 chiavi si ha una fiducia piena (0f, f="I trust fully"), ed infine per una chiave si ha una fiducia assoluta (1u, u="I trust ultimately"). E questo è ovvio, dal momento che la chiave appartiene a noi

La terza riga dell'output analizza le chiavi di livello 1 nel nostro keyring. Abbiamo 7 chiavi pienamente valide, dal momento che sono state firmate utilizzando le nostre credenziali private. Inoltre tra le chiavi presenti nel keyring, 3 di esse non sono state firmate da noi ma hanno una firma di almeno una delle chiavi pienamente valide. I contatori dei livelli di trust hanno lo stesso significato di quelli della seconda riga. Questa volta abbiamo 4 chiavi firmate direttamente da noi, ma per le quali non si ripone alcuna fiducia nel titolare per quanto riguarda la sua capacità di verificare l'identità delle persone di cui firma le chiavi. D'altra parte, 3 delle 7 chiavi firmate da noi hanno un livello di trust marginale, ovvero siamo solo marginalmente confidenti che la persona titolare di queste chiavi possa adeguatamente verificare l'identità delle persone di cui firma le chiavi.

-- NetWalker - 14 May 2006