[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico] [volume] [parte]
GnuPG (1) è uno strumento per la gestione della crittografia e delle firme elettroniche, compatibile con le specifiche OpenPGP pubblicate nell'RFC 2440. Rispetto al noto PGP, si tratta di software libero e in particolare non vengono utilizzati algoritmi proprietari. Tuttavia, nonostante queste sue caratteristiche, viene diffuso soltanto attraverso siti europei, a causa delle limitazioni all'esportazione poste dal governo degli Stati Uniti.
GnuPG è composto da due eseguibili: gpg e gpgm. Di solito, il secondo viene richiamato dal primo, in base alle necessità, senza che ci sia bisogno di utilizzarlo direttamente. La distinzione in due eseguibili dipende dall'esigenza di distinguere le operazioni delicate dal punto di vista della sicurezza, da quelle che non hanno questo problema. Nel primo caso si deve fare uso di memoria «sicura», nel secondo non esiste questo bisogno. Tra le altre cose, da questo problema legato alla memoria dipende la limitazione pratica nella dimensione delle chiavi che si possono gestire.
Una volta chiarito che basta utilizzare solo l'eseguibile gpg, occorre vedere come sono organizzati gli argomenti nella sua riga di comando:
gpg [opzioni] comando [argomenti_del_comando]
In pratica, si utilizza gpg esattamente con l'indicazione di un comando. Il funzionamento generale può essere definito attraverso le opzioni che precedono tale comando, mentre il comando stesso potrebbe richiedere l'indicazione di altri argomenti.(2)
Le opzioni «lunghe», cioè quelle che andrebbero indicate con due trattini iniziali, possono essere inserite in un file di configurazione, avendo però l'accortezza di eliminare i due trattini. Il file di configurazione di GnuPG è sempre solo personale, il nome predefinito è ~/.gnupg/options e di solito viene creato automaticamente la prima volta che si usa il programma (assieme alla directory che lo precede). Come in molti altri tipi di file del genere, il carattere # viene utilizzato per iniziare un commento, mentre le righe bianche e quelle vuote vengono ignorate nello stesso modo. In particolare, negli esempi che verranno mostrati, si fa riferimento alla situazione tipica, in cui non viene modificato il file di configurazione creato automaticamente e tutto quello che serve deve essere definito attraverso la riga di comando.
Come si può intuire, la directory ~/.gnupg/ serve anche per contenere altri file relativi al funzionamento di GnuPG, tenendo conto, comunque, che in condizioni normali viene creata la prima volta che si avvia l'eseguibile gpg. I file più importanti che si possono trovare sono: ~/.gnupg/secring.gpg, che rappresenta il portachiavi delle chiavi private (file che deve essere custodito e protetto gelosamente); ~/.gnupg/pubring.gpg, che rappresenta il portachiavi delle chiavi pubbliche (ovvero dei certificati); ~/.gnupg/trustdb.gpg, che contiene le informazioni sulla propria fiducia nei confronti di altre persone che possono avere firmato (certificato) le chiavi pubbliche di altri.
Ogni volta che c'è bisogno di accedere a questi file, viene creato un file di lock, con lo stesso nome del file a cui si riferisce e l'aggiunta dell'estensione .lock. Alle volte, se si interrompe il funzionamento dell'eseguibile gpg, possono rimanere questi file, che poi impediscono di accedere ai dati. Se ciò accade, viene segnalato dal programma, che indica anche il numero che dovrebbe avere il processo che li ha bloccati: se questo processo non c'è, vuol dire che i file di lock possono essere rimossi.
La creazione di una coppia di chiavi è un'operazione molto semplice. Quello che occorre considerare prima è il modo in cui verrà gestito il file che rappresenta il portachiavi privato, come è già stato descritto. In particolare, occorre considerare subito la possibilità di creare un certificato di revoca, che in pratica è un codice che permette di annullare ufficialmente una chiave, quando per qualche ragione non può più essere utilizzata (per esempio perché è stata rubata, oppure perché è stata persa semplicemente).
Si comincia con la creazione di una coppia di chiavi, utilizzando il comando --gen-key. Se non erano stati creati prima, viene predisposta la directory ~/.gnupg/ con i vari portachiavi.
tizio$ gpg --gen-key[Invio]
Please select what kind of key you want: (1) DSA and ElGamal (default) (2) DSA (sign only) (4) ElGamal (sign and encrypt)
A questo punto iniziano una serie di richieste con le quali si devono stabilire le caratteristiche delle chiavi che si creano. Per vari motivi, è conveniente affidarsi alle scelte predefinite, a meno di avere le idee chiare al riguardo.
Your selection? 1[Invio]
DSA keypair will have 1024 bits.
About to generate a new ELG-E keypair.
minimum keysize is 768 bits
default keysize is 1024 bits
highest suggested keysize is 2048 bits
What keysize do you want? (1024) [Invio]
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Questo può essere un punto delicato. Di solito si crea una coppia di chiavi che non scadono mai, ma per motivi di sicurezza si potrebbe stabilire una scadenza. Ribadendo che in condizioni normali si crea una coppia di chiavi senza scadenza, negli esempi si mostra la creazione di una chiave che scade alla fine di una settimana.
Key is valid for? (0) 1w[Invio]
Key expires at Fri Oct 8 10:55:43 1999 CEST
Is this correct (y/n)? y[Invio]
Per completare questa fase occorre indicare i dati personali che vengono uniti alle chiavi, in modo da facilitarne il riconoscimento.
You need a User-ID to identify your key; the software constructs the user id
from Real Name, Comment and Email Address in this form:
"Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"
Come si vede, si tratta di indicare il proprio nome e cognome, quindi verrà richiesto un indirizzo di posta elettronica, infine viene proposta la possibilità di mettere una nota, che potrebbe essere un nomignolo o qualunque altra cosa che possa aiutare a individuare il proprietario della chiave.
Real name: Tizio Tizi[Invio]
Email address: tizio@dinkel.brot.dg[Invio]
Comment: Baffo[Invio]
You selected this USER-ID:
"Tizio Tizi (Baffo) <tizio@dinkel.brot.dg>"
Il programma mostra i dati inseriti, permettendo di controllarli. Se tutto è in ordine, si conferma.
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O[Invio]
Infine, la cosa più importante: per proteggere la chiave privata, questa viene cifrata utilizzando una parola d'ordine, che in questo caso viene definita precisamente passphrase, per intendere che si dovrebbe trattare di un testo più lungo di una sola parola. In pratica, si deve inserire una stringa, possibilmente lunga e complicata, che verrà utilizzata per cifrare la chiave privata: ogni volta che dovrà essere utilizzata la chiave privata, verrà richiesto l'inserimento di questa stringa per potervi accedere.
You need a Passphrase to protect your secret key.
Enter passphrase: digitazione_all'oscuro[Invio]
Repeat passphrase: digitazione_all'oscuro[Invio]
Completata questa fase, inizia la procedura di creazione delle chiavi, che avviene in modo automatico.
We need to generate a lot of random bytes. It is a good idea to perform some other action (work in another window, move the mouse, utilize the network and the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. ....+++++..............+++++..+++++.+++++.............+++++......+++++..++++++++ ++........+++++..+++++........++++++++++................................+++++.++ +++.+++++....+++++........+++++...+++++........++++++++++..+++++++++++++++.+++++ ......+++++.+++++>......+++++>.........+++++.<.+++++............>.........+++++. ...<+++++...>.....+++++<..+++++................................................. ................................................................................ ....+++++^^^ public and secret key created and signed.
Questo conclude il funzionamento del programma e riappare l'invito della shell. Leggendo il messaggio finale, si osserva che le chiavi sono state firmate. Questa firma garantisce solo che non siano alterate le informazioni abbinate alle chiavi, ma come è già stato spiegato nel capitolo introduttivo (195), ciò non impedisce che qualcuno possa sostituire completamente le chiavi pubbliche che vengono diffuse.
|
Una volta creata la propria coppia di chiavi, è importantissimo provvedere a generare anche il certificato di revoca relativo. Questo si traduce in un file di testo da conservare in un posto sicuro. Eventualmente, si può anche stampare il file, per una maggiore sicurezza. |
tizio$ gpg --output revoca.txt --gen-revoke tizio@dinkel.brot.dg[Invio]
sec 1024D/7A6D2F72 1999-10-01 Tizio Tizi (Baffo) <tizio@dinkel.brot.dg>
Come si vede, vengono mostrati tutti i dati identificativi della chiave, compreso il numero che è stato generato automaticamente. Per proseguire basta confermare.
Create a revocation certificate for this key? y[Invio]
Dal momento che questa operazione richiede l'utilizzo della chiave privata, occorre indicare la stringa necessaria per sbloccarla.
You need a passphrase to unlock the secret key for user: "Tizio Tizi (Baffo) <tizio@dinkel.brot.dg>" 1024-bit DSA key, ID 7A6D2F72, created 1999-10-01
Enter passphrase: digitazione_all'oscuro[Invio]
ASCII armored output forced. Revocation certificate created. Please move it to a medium which you can hide away; if Mallory gets access to this certificate he can use it to make your key unusable. It is smart to print this certificate and store it away, just in case your media become unreadable. But have some caution: The print system of your machine might store the data and make it available to others!
E con questo si conclude l'operazione che ha generato il file revoca.txt. Il file è di tipo ASCII, ovvero, da binario è stato convertito in ASCII attraverso l'algoritmo Armor. Vale la pena di vedere come potrebbe essere questo file:
-----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v0.9.3 (GNU/Linux) Comment: For info see http://www.gnupg.org Comment: A revocation certificate should follow iEYEIBECAAYFAjf0gEIACgkQZUnKKXptL3KOAQCdEH5HfbFR5g34fui5y0JMkQxr PisAn2kHENgFOLtkdDIpK1PwYp9ZArbK =HGaY -----END PGP PUBLIC KEY BLOCK-----
Quando si vuole intrattenere una comunicazione cifrata con qualcuno, si deve disporre della chiave pubblica dell'interlocutore, che a sua volta deve disporre di quella della controparte. Di conseguenza, è necessario apprendere subito come si accede al proprio portachiavi, in modo da poter estrarre le chiavi pubbliche (proprie o di altri) e per potervi aggiungere le chiavi delle persone con cui si vogliono avere contatti in questa forma. Inizialmente, le chiavi pubbliche a disposizione sono solo le proprie; se ne ottiene l'elenco con il comando seguente:
tizio$ gpg --list-keys[Invio]
/home/tizio/.gnupg/pubring.gpg ------------------------------------------ pub 1024D/7A6D2F72 1999-10-01 Tizio Tizi (Baffo) <tizio@dinkel.brot.dg> sub 1024g/D75594A6 1999-10-01
Anche se non è stato richiesto esplicitamente, nella creazione della coppia di chiavi complementari, in realtà sono state generate due coppie: una primaria e una secondaria. Si può osservare che la prima colonna suggerisce di che tipo di chiave si tratti: pub per indicare la chiave pubblica primaria e sub per indicare la chiave pubblica secondaria.
A questo punto si pone il problema di esportare la propria chiave pubblica (intesa come il complesso rappresentato dalla chiave primaria e da tutte le sue chiavi secondarie) e di importare quella degli interlocutori futuri. In particolare, nel momento in cui si esporta una chiave, occorre decidere se questo debba essere fatto generando un risultato binario, oppure se lo si voglia convertire in ASCII. In generale, dovendo preparare un file da trasmettere attraverso forme di comunicazione tradizionale, come la posta elettronica, conviene richiedere sempre la conversione in ASCII, per mezzo dell'opzione --armor. Si comincia mostrando l'esportazione.
tizio$ gpg --armor --output tizio.gpg --export tizio@dinkel.brot.dg[Invio]
Il file che si ottiene, tizio.gpg, potrebbe essere simile a quello seguente (che viene mostrato solo in parte):
-----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v0.9.3 (GNU/Linux) Comment: For info see http://www.gnupg.org mQGiBDf0ehMRBAC+s8Evv4EXv1eEGDw01mZAwJCPe9uBbE/u9eNlD8J33MCXFRUK k/4CFU6BRK46RlXFjL9CcWtRIDar/72NIktChpBFebYnX+wiho9Pt2/U7B32MbMX ... ... vO+Y8kqiOfAHDrL90IhMBBgRAgAMBQI39HpKBQkACTqAAAoJEGVJyil6bS9y0ywA n3OySw4T4rHtGtE2hULTwj9orwefAKCB3ozbH0x/I9jFrCGe6gx7Fio9FA== =jTTe -----END PGP PUBLIC KEY BLOCK-----
L'importazione di una chiave pubblica avviene in modo analogo, con la differenza che non è necessario specificare in che formato sia la fonte: ciò viene determinato automaticamente. Si suppone di importare una chiave contenuta nel file caio.gpg.
tizio$ gpg --import caio.gpg[Invio]
gpg:/home/tizio/caio.gpg: key C38563D0: public key imported gpg: Total number processed: 1 gpg: imported: 1
Dopo l'importazione si può controllare l'elenco delle chiavi pubbliche possedute, come era già stato fatto in precedenza.
tizio$ gpg --list-keys[Invio]
/home/tizio/.gnupg/pubring.gpg ------------------------------------------ pub 1024D/7A6D2F72 1999-10-01 Tizio Tizi (Baffo) <tizio@dinkel.brot.dg> sub 1024g/D75594A6 1999-10-01 pub 1024D/C38563D0 1999-10-01 Caio Cai <caio@roggen.brot.dg> sub 1024g/E3460DB4 1999-10-01
|
È da osservare il fatto che l'esportazione delle chiavi pubbliche, senza indicare a quali persone si vuole fare riferimento, implica l'esportazione completa di tutte le chiavi disponibili. |
A questo punto, occorre stabilire se ci si fida o meno delle chiavi pubbliche che si importano. Se si è certi della loro autenticità, è utile controfirmarle. La firma che si aggiunge potrà servire a qualcun altro, se poi si provvederà a diffonderle nuovamente. Per intervenire a questo livello nel portachiavi pubblico, occorre usare il comando --edit-key:
tizio$ gpg --edit-key caio@roggen.brot.dg[Invio]
Con questo comando si richiede di intervenire nella chiave pubblica di Caio. Si ottiene un riassunto della situazione e un invito a inserire dei comandi specifici (attraverso una riga di comando).
pub 1024D/C38563D0 created: 1999-10-01 expires: 1999-10-08 trust: -/q sub 1024g/E3460DB4 created: 1999-10-01 expires: 1999-10-08 (1) Caio Cai <caio@roggen.brot.dg>
|
Una chiave potrebbe contenere più informazioni riferite all'identità del suo proprietario. Anche se si tratta sempre della stessa persona, questa potrebbe utilizzare diversi indirizzi di posta elettronica e diverse variazioni nel nome (per esempio per la presenza o meno del titolo o di un nomignolo). Nel caso mostrato dall'esempio, si tratta di un nominativo soltanto, a cui è abbinato il numero uno. |
Tanto per cominciare, si può controllare lo stato di questa chiave con il comando check:
Command> check[Invio]
uid Caio Cai <caio@roggen.brot.dg> sig! C38563D0 1999-10-01 [self-signature]
Si può osservare che dispone soltanto della firma del suo stesso proprietario, cosa che non può garantirne l'autenticità. Di solito, per verificare l'origine di una chiave pubblica si sfrutta la sua impronta digitale, ovvero un codice più breve che viene generato univocamente attraverso una funzione apposita:
Command> fpr[Invio]
Con il comando fpr si ottiene proprio questa informazione. Se il proprietario di questa chiave ci ha fornito l'impronta digitale attraverso un canale sicuro (di solito ciò significa che c'è stato un incontro personale), si può controllare a vista la sua corrispondenza.
pub 1024D/C38563D0 1999-10-01 Caio Cai <caio@roggen.brot.dg>
Fingerprint: 8153 E6E4 DE1F 6B62 2847 0B5D 9643 B918 C385 63D0
Se l'impronta corrisponde e si è finalmente certi dell'autenticità di questa chiave, la si può firmare, certificando a proprio nome che si tratta di una chiave autentica.
Command> sign[Invio]
pub 1024D/C38563D0 created: 1999-10-01 expires: 1999-10-08 trust: -/q
Fingerprint: 8153 E6E4 DE1F 6B62 2847 0B5D 9643 B918 C385 63D0
Caio Cai <caio@roggen.brot.dg>
Are you really sure that you want to sign this key
with your key: "Tizio Tizi (Baffo) <tizio@dinkel.brot.dg>"
Really sign? y[Invio]
Dal momento che per farlo occorre utilizzare la propria chiave privata, ecco che viene richiesto di inserire la stringa necessaria per sbloccarla.
You need a passphrase to unlock the secret key for user: "Tizio Tizi (Baffo) <tizio@dinkel.brot.dg>" 1024-bit DSA key, ID 7A6D2F72, created 1999-10-01
Enter passphrase: digitazione_all'oscuro[Invio]
A questo punto si può verificare nuovamente lo stato della chiave:
Command> check[Invio]
uid Caio Cai <caio@roggen.brot.dg> sig! C38563D0 1999-10-01 [self-signature] sig! 7A6D2F72 1999-10-01 Tizio Tizi (Baffo) <tizio@dinkel.brot.dg
Come si vede, adesso c'è anche la firma di Tizio. Per concludere questo funzionamento interattivo, si utilizza il comando quit, ma prima si salvano le modifiche con save:
Command> save[Invio]
Command> quit[Invio]
Quando si dispone della chiave pubblica del proprio interlocutore, è possibile cifrare i dati che gli si vogliono mandare. In generale, si lavora su un file alla volta, o eventualmente su un archivio compresso contenente più file. Supponendo di volere inviare il file documento.txt a Caio, si potrebbe preparare una versione cifrata di questo file con il comando seguente:
tizio$ gpg --output documento.txt.gpg --encrypt <-'
`->--recipient caio@roggen.brot.dg documento.txt[Invio]
In questo modo si ottiene il file documento.txt.gpg. Se questo file viene spedito attraverso la posta elettronica, allegandolo a un messaggio, di solito, il programma che si usa si arrangia a convertirlo in un formato adatto a questa trasmissione; diversamente, può essere conveniente la conversione in formato Armor. Nell'esempio seguente si fa tutto in un colpo solo: si cifra il messaggio e lo si spedisce a Caio (si osservi il trasferimento del messaggio cifrato attraverso lo standard output.)
tizio$ gpg --armor --output - --encrypt --recipient <-'
`->caio@roggen.brot.dg documento.txt | mail caio@roggen.brot.dg[Invio]
Eventualmente si può specificare in modo esplicito l'algoritmo da usare per cifrare. Si ottiene questo con l'opzione --cipher-algo, ma prima occorre conoscere gli algoritmi a disposizione:
tizio$ gpg --version[Invio]
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
Si possono usare i nomi elencati per la cifratura; per esempio, volendo usare l'algoritmo 3DES:
tizio$ gpg --output documento.txt.gpg --encrypt <-'
`->--cipher-algo 3DES --recipient caio@roggen.brot.dg <-'
`->documento.txt[Invio]
Per decifrare un documento si agisce in modo simile, utilizzando l'opzione --decrypt. A differenza dell'operazione di cifratura, dovendo usare la chiave privata, viene richiesta l'indicazione della stringa necessaria per sbloccarla. L'esempio che segue, mostra il caso in cui si voglia decifrare il contenuto del file messaggio.gpg, generando il file messaggio:
tizio$ gpg --output messaggio --decrypt messaggio.gpg[Invio]
You need a passphrase to unlock the secret key for user: "Tizio Tizi (Baffo) <tizio@dinkel.brot.dg>" 1024-bit DSA key, ID 7A6D2F72, created 1999-10-01
Enter passphrase: digitazione_all'oscuro[Invio]
Per finire, è il caso di considerare anche la possibilità di usare un sistema di crittografia simmetrica (a chiave segreta), dove non viene presa in considerazione la gestione delle chiavi pubbliche o private che siano. In pratica, tutto si riduce a definire la chiave da usare per la cifratura, chiave che deve essere conosciuta anche dalla nostra controparte, per poter decifrare il messaggio.
tizio$ gpg --armor --output testo.gpg --symmetric testo[Invio]
L'esempio mostra il caso del file testo che viene cifrato generando il file testo.gpg, in formato ASCII Armor. Per completare l'operazione, occorre fornire la stringa da usare come chiave per la cifratura; per ridurre la possibilità di errori, ciò viene richiesto per due volte:
Enter passphrase: digitazione_all'oscuro[Invio]
Repeat passphrase: digitazione_all'oscuro[Invio]
Per decifrare questo file, non occorrono comandi speciali, basta l'opzione --decrypt. GnuPG si accorge da solo che si tratta di una cifratura simmetrica, provvedendo a chiedere l'indicazione della stringa necessaria a decifrarla.
La firma elettronica (o digitale) serve a certificare l'autenticità e la data di un file. Se il file in questione viene modificato in qualche modo, la verifica della firma fallisce. La firma viene generata utilizzando la chiave privata e di conseguenza può essere verificata utilizzando la chiave pubblica; il controllo ha valore solo se si può dimostrare l'autenticità della chiave pubblica. In generale, la firma viene allegata allo stesso file, che di solito viene cifrato, sempre usando la chiave privata.
tizio$ gpg --armor --output documento.firmato --sign documento[Invio]
L'esempio mostra in che modo si può firmare il file documento, generando documento.firmato (in particolare si vuole ottenere un file ASCII per facilitarne la trasmissione).
You need a passphrase to unlock the secret key for user: "Tizio Tizi (Baffo) <tizio@dinkel.brot.dg>" 1024-bit DSA key, ID 7A6D2F72, created 1999-10-01
Dal momento che si deve usare la chiave privata per ottenere la firma e anche per cifrare il testo, viene richiesto di inserire la stringa necessaria per sbloccarla.
Enter passphrase: digitazione_all'oscuro[Invio]
Un documento firmato si controlla semplicemente con l'opzione --verify, come nell'esempio seguente:
tizio$ gpg --verify documento.firmato[Invio]
gpg: Signature made Fri Oct 1 15:56:15 1999 CEST using DSA key ID 7A6D2F72 gpg: Good signature from "Tizio Tizi (Baffo) <tizio@dinkel.brot.dg>"
Dal momento che il documento, così come si trova non è leggibile, occorre richiedere di decifrarlo, cosa che implica anche la verifica della firma:
tizio$ gpg --output documento --decrypt documento.firmato[Invio]
In questo caso si ottengono le stesse informazioni di prima, ma in più si ha di nuovo il file documento originale.
gpg: Signature made Fri Oct 1 15:56:15 1999 CEST using DSA key ID 7A6D2F72 gpg: Good signature from "Tizio Tizi (Baffo) <tizio@dinkel.brot.dg>"
Dal momento che lo scopo della firma non è quello di nascondere il contenuto del file originale, specialmente se si tratta di un file di testo, si può richiedere esplicitamente di firmare un file in chiaro. In pratica, si ottiene il file di partenza, con l'aggiunta della firma. Per questo si usa il comando --clearsign al posto di --sign:
tizio$ gpg --output documento.firmato --clearsign documento[Invio]
Tutto il resto funziona come prima. L'aspetto di un file del genere è simile a quello seguente:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ... ... -----BEGIN PGP SIGNATURE----- Version: GnuPG v0.9.3 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE39L/LrL80KSMdTVQRAgUfAJ9tVPiBLuJNpElEF9fpoUO27odWMQCfc8e7 3c6ARR8UGBAO7TIhVlDn7fE= =amzF -----END PGP SIGNATURE-----
Infine, se può essere opportuno per qualche motivo, la firma si può tenere staccata dal file originale. In questo caso, si utilizza il comando --detach-sig:
tizio$ gpg --armor --output firma --detach-sig documento[Invio]
In questo modo si crea la firma del file documento, inserendola separatamente nel file firma, richiedendo espressamente di utilizzare la codifica ASCII Armor. Per verificare la firma, occorre indicare i due nomi:
tizio$ gpg --verify firma documento[Invio]
GnuPG permette di annotare il livello di fiducia che si ha nei confronti della certificazione da parte di altre persone. Una volta definiti questi valori, si può automatizzare il calcolo della credibilità di una chiave pubblica della quale si è venuti in possesso. In pratica, se ci si fida ciecamente del giudizio di Sempronio, si accetteranno come valide tutte le chiavi pubbliche controfirmate anche da Sempronio. Per accedere a queste funzioni, si utilizza il solito comando --edit-key; quindi, nell'ambito del funzionamento interattivo che si ottiene, si utilizza il comando trust.
$ gpg --edit-key caio@roggen.brot.dg[Invio]
pub 1024D/C38563D0 created: 1999-10-01 expires: 1999-10-08 trust: -/q sub 1024g/E3460DB4 created: 1999-10-01 expires: 1999-10-08 (1) Caio Cai <caio@roggen.brot.dg>
Dopo aver ottenuto la situazione della chiave pubblica di Caio e delle sue sottochiavi, si può richiedere di passare alla gestione della fiducia nei suoi confronti.
Command> trust[Invio]
pub 1024D/C38563D0 created: 1999-10-01 expires: 1999-10-08 trust: -/q sub 1024g/E3460DB4 created: 1999-10-01 expires: 1999-10-08 (1) Caio Cai <caio@roggen.brot.dg> Please decide how far you trust this user to correctly verify other users' keys (by looking at passports, checking fingerprints from different sources...)? 1 = Don't know 2 = I do NOT trust 3 = I trust marginally 4 = I trust fully s = please show me more information m = back to the main menu
In breve: il valore uno corrisponde a un livello indefinibile; due fa riferimento a una persona inaffidabile; tre rappresenta una fiducia parziale; quattro è una fiducia completa. Viene mostrato il caso in cui si indica una fiducia parziale.
Your decision? 3[Invio]
pub 1024D/C38563D0 created: 1999-10-01 expires: 1999-10-08 trust: m/q sub 1024g/E3460DB4 created: 1999-10-01 expires: 1999-10-08 (1) Caio Cai <caio@roggen.brot.dg>
Command> quit[Invio]
A questo punto è importante definire il significato delle lettere che appaiono sulla destra, nel campo trust:. Come si vede dagli esempi, si tratta di due lettere staccate da un barra obliqua: la prima lettera definisce il grado di fiducia nei confronti della persona; la seconda definisce la fiducia sull'autenticità della sua chiave pubblica. Infatti, la fiducia nei confronti di una firma, è condizionata dal fatto che la chiave pubblica che si dispone per il controllo sia effettivamente quella giusta (e non una contraffazione). La tabella 196.1 mostra l'elenco di queste lettere, assieme alla descrizione del loro significato.
Tabella 196.1. Elenco degli indicatori utilizzati per definire i livelli di fiducia.
| Lettera | Significato |
| - | Fiducia indefinita nei confronti della persona. |
| e | Calcolo della fiducia fallito. |
| q | Informazioni insufficienti per il calcolo della fiducia. |
| n | Non viene attribuita alcuna fiducia alla chiave. |
| m | Fiducia parziale nei confronti della persona. |
| f | Fiducia totale nei confronti della persona. |
| u | Certezza assoluta dell'autenticità della chiave. |
Una volta stabilito il livello di fiducia nei confronti delle persone e delle loro chiavi pubbliche, si può stabilire in che modo le altre chiavi controfirmate da questi possono essere acquisite nel proprio portachiavi. In generale, salvo la modifica della configurazione predefinita, valgono le regole seguenti:
una chiave firmata personalmente è valida a tutti gli effetti;
una chiave firmata da una persona fidata è trattata come autentica se la sua stessa chiave pubblica è ritenuta sicura;
una chiave firmata da almeno tre persone di cui ci si fida in parte è trattata come autentica se le loro stesse chiavi pubbliche sono ritenute sicure.
Oltre a questo elenco si deve considerare anche il «percorso di fiducia». Forse si comprende meglio il problema pensando per analogia alle firme poste su un assegno bancario per girarlo: la prima girata (la prima firma posta sul retro) è quella della persona a cui è destinato l'assegno (spesso è la stessa persona che lo ha emesso a proprio nome), mentre le firme successive sono quelle di persone che si sono passate di mano l'assegno. Se Sempronio è l'ultimo di questi e ci si fida di lui, mentre degli altri non si sa nulla, diventa difficile accettare un assegno del genere quando l'elenco delle girate comincia a diventare lungo. Ecco quindi il senso di questo percorso di fiducia, che rappresenta il numero di persone attraverso le quali la chiave pubblica giunge al nostro portachiavi. In generale, per poter accettare come valida una chiave, è necessario anche che il percorso di fiducia sia minore o al massimo uguale a cinque passaggi.
Prima di accedere a un servente di chiavi, occorre determinare quale possa essere quello più comodo rispetto alla propria posizione nella rete.
Supponendo di avere scelto il nodo www.it.pgp.net, ammesso che si tratti effettivamente di un servente di chiavi, si può utilizzare lo stesso GnuPG per prelevare le chiavi pubbliche di nostro interesse, purché se ne conosca il numero di identificazione:
$ gpg --keyserver www.it.pgp.net --recv-key 0x0C9857A5[Invio]
gpg: requesting key 0C9857A5 from www.it.pgp.net ... gpg: key 0C9857A5: 1 new signature gpg: Total number processed: 1 gpg: new signatures: 1
Per l'invio della propria chiave pubblica, si agisce in modo simile:
$ gpg --keyserver www.it.pgp.net --send-key tizio@dinkel.brot.dg[Invio]
gpg: success sending to 'www.it.pgp.net' (status 200)
|
Se per qualche motivo i serventi di chiavi locali non consentono l'accesso, si può sempre riparare presso |
The GNU Privacy Handbook, 1999
Bert-Jaap Coops, Crypto law survey
daniele @ swlibero.org2) In questo contesto, il comando è un'opzione che ha un ruolo particolare.
Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome gnupg_gnu_privacy_guard.html
[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico]