Manual Gnu
Manual Gnu
Manual Gnu
Si prega di rivolgere domande, segnalazioni di errori o suggerimenti riguardanti questo manuale al manutentore Mike
Ashley (<[email protected]>) o al traduttore Lorenzo Cappelletti (<[email protected]>). Riferendosi
al manuale, si prega di specificare di quale versione si è in possesso utilizzando, per il documento in lingua originale
la stringa di revisione $Revision: 1.11 $, per quello presente tradotto in italiano la stringa $Revision: 1.2 $.
Hanno contribuito a questo manuale Matthew Copeland, Joergen Grahn, and David A. Wheeler. J Horacio MG ha
tradotto il manuale in spagnolo, Lorenzo Cappelletti in italiano.
È concesso il permesso di copiare, distribuire e/o modificare questo documento secondo i termini della licenza GNU Free Documentation,
versione 1.1 o qualsiasi altra versione successiva pubblicata dalla Free Software Foundation, senza nessuna Sezione Invariante, nessun Testo
Copertina, né Testo di Retro Copertina. Una copia della licenza originale è inclusa nella sezione intitolata "Licenza GNU Free Documentation"
alla quale segue una traduzione italiana priva, però, di qualche valore legale.
iii
8. TRANSLATION ..........................................................................................................................35
9. TERMINATION...........................................................................................................................35
10. FUTURE REVISIONS OF THIS LICENSE.............................................................................35
How to use this License for your documents ...................................................................................36
B. GNU Free Documentation License (traduzione italiana) ................................................................37
0. PREAMBOLO .............................................................................................................................37
1. APPLICABILITÀ E DEFINIZIONI............................................................................................37
2. COPIE ALLA LETTERA............................................................................................................38
3. COPIARE IN NOTEVOLI QUANTITÀ .....................................................................................38
4. MODIFICHE ...............................................................................................................................39
5. UNIONE DI DOCUMENTI ........................................................................................................40
6. RACCOLTE DI DOCUMENTI ...................................................................................................41
7. RACCOGLIERE INSIEME A LAVORI INDIPENDENTI ........................................................41
8. TRADUZIONI .............................................................................................................................41
9. TERMINI .....................................................................................................................................42
10. REVISIONI FUTURE DI QUESTA LICENZA .......................................................................42
Come usare questa licenza per i vostri documenti ...........................................................................42
iv
Lista delle Figure
3-1. Un’ipotetica rete della fiducia ............................................................................................................21
v
Capitolo 1. Incominciamo
GnuPG è uno strumento per comunicare in modo sicuro. Questo capitolo è una breve guida riguardante il
nocciolo funzionale di GnuPG; include la creazione di coppie di chiavi, scambio e verifica di chiavi,
cifratura e decifratura di documenti e autenticazione di documenti con firme digitali. Non spiega invece
nel dettaglio i concetti che stanno dietro alla crittografia a chiave pubblica, alla cifratura e alle firme
digitali. Tali argomenti, infatti, vengono trattati nel capitolo 2. Il presente capitolo non spiega nemmeno
come usare GnuPG con una certa cognizione di causa; ciò fa parte dei capitoli 3 e 4.
GnuPG utilizza la crittografia a chiave pubblica per permettere a coloro che lo utilizzano di comunicare
in sicurezza. In un sistema a chiave pubblica ogni utente ha una coppia di chiavi consistenti in una chiave
privata e una chiave pubblica. La chiave privata di una persona viene tenuta segreta; non deve mai essere
rivelata. La chiave pubblica può essere data a tutti coloro con i quali l’utente vuole comunicare. GnuPG
utilizza uno schema in qualche modo più sofisticato per il quale un utente possiede una coppia di chiavi
primaria e zero o più coppie di chiavi subordinate addizionali. La coppia di chiavi primaria e quelle
subordinate sono raggruppate assieme per facilitare la gestione delle chiavi e il mazzo così ottenuto può
spesso essere considerato semplicemente come un’unica coppia di chiavi.
GnuPG è in grado di creare diversi tipi di coppie di chiavi, ma una chiave primaria deve essere capace di
fare firme. Ci sono pertanto solo tre opzioni. L’opzione 1 crea in realtà due coppie di chiavi: una coppia
di chiavi di tipo DSA che rappresenta la coppia di chiavi primaria ed è utilizzabile solo per firmare; una
coppia di chiavi subordinata di tipo ElGamal, usata per criptare. L’opzione 2 è simile alla precedente ma
crea solo una coppia di chiavi DSA. L’opzione 41crea una singola coppia di chiavi ElGamal utilizzabile
sia per firmare che per criptare. In tutti i casi è possibile in un secondo momento creare sotto-chiavi
addizionali per cifrature e firme.
È necessario anche scegliere la dimensione della chiave. La dimensione di una chiave DSA deve essere
compresa fra 512 e 1024 bit mentre una chiave ElGamal può essere di qualsiasi dimensione. GnuPG,
però, richiede che le chiavi non siano più piccole di 768 bit. Accade quindi che, se si è scelta l’opzione 1
e successivamente si sceglie una dimensione per la chiave maggiore di 1024 bit, la chiave ElGamal avrà
la dimensione richiesta, mentre la chiave DSA sarà di 1024 bit.
Sto per generare una nuova coppia di chiavi ELG-E.
la dimensione minima è 768 bit
la dimensione predefinita è 1024 bit
1
Capitolo 1. Incominciamo
Più lunga è la chiave maggiore è la sicurezza contro attacchi a forza bruta, anche se in pratica per un
utilizzo comune la dimensione di default della chiave è adeguata. Con una chiave lunga, infatti, diventa
più economico aggirare la cifratura piuttosto che provare a romperla. Inoltre cifratura e decifratura sono
più lente e una dimensione maggiore della chiave può influenzare negativamente la lunghezza della
firma. Una volta scelta, la dimensione della chiave non può più essere modificata.
Infine è necessario scegliere una data di scadenza. Se è stata scelta l’opzione 1, la data di scadenza verrà
utilizzata sia per la coppia di chiavi ElGamal che per quella DSA.
Per favore specifica per quanto 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)
Per la maggior parte degli utenti una chiave che non scade risulta adeguata. Il tempo di scadenza, in caso
contrario, dovrebbe essere scelto con cura in quanto, anche se è possibile cambiare la data di scadenza
dopo che la chiave è stata creata, potrebbe risultare dificile comunicare un cambiamento alle persone che
possiedono quella chiave pubblica.
È necessario fornire un identificativo utente2 in aggiunta ai parametri della chiave. Lo User ID viene
utilizzato per associare la chiave che si sta creando ad una persona reale.
Ti serve uno User ID per identificare la tua chiave; il software costruisce l’user id a partire da Nome e Cogn
"Heinrich Heine (Der Dichter) <[email protected]>"
Nome e Cognome:
Solamente uno User ID viene creato nel momento in cui si genera una nuova chiave. È comunque
possibile aggiungere ulteriori User ID in seguito nel caso in cui si desiderasse utilizzare la chiave in due
o più contesti diversi, come ad esempio sul lavoro e all’interno della propria sezione di partito. Uno User
ID deve essere creato con cura in quanto non può più essere modificato.
GnuPG necessita di una “frase d’ordine”3 per proteggere le chiavi primarie e subordinate che si
possiedono.
Ti serve una passphrase per proteggere la tua chiave segreta.
Inserisci la passphrase:
Non ci sono limiti alla lunghezza della passphrase, la quale dovrebbe essere scelta con attenzione. Dal
punto di vista della sicurezza, la passphrase usata per sbloccare la chiave privata è uno dei punti più
deboli di GnuPG (così come di altri sistema di crittografia a chiave pubblica), in quanto è l’unica
protezione che si possiede nel caso in cui un’altra persona entri in possesso della propria chiave privata.
Idealmente la passphrase non dovrebbe utilizzare parole prese da un dizionario e dovrebbe usare tanto
caratteri minuscoli e minuscoli quanto caratteri non-alfabetici. Una buona passphrase è cruciale per un
uso sicuro di GnuPG.
2
Capitolo 1. Incominciamo
L’argomento mia_chiave deve essere uno specificatore di chiave, cioè o l’ID della propria coppia
primaria di chiavi o una qualsiasi altra parte dello User ID che identifica la propria coppia di chiavi. Il
certificato generato verrà riposto nel file revoca.asc. Se l’opzione --output è omessa, il risultato
verrà stampato sullo standard output. Poiché il certificato è breve, si può pensare di stamparne una copia
e tenerlo al sicuro da qualche parte, ad esempio nella propria cassetta di sicurezza. Il certificato non
dovrebbe venir riposto in luoghi dove altri possono aver accesso in quanto chiunque può pubblicare il
certificato di revoca e rendere la chiave pubblica corrispondente inutile.
La chieve è esportata in un formato binario, ma ciò può risultare sconveniente quando la chiave viene
spedita per posta elettronica o pubblicata in una pagina web. GnuPG supporta perciò l’opzione a linea di
comando --armor4 che forza l’output ad essere generato in un formato protetto da un’armatura ASCII5
simile ai documenti codificati con uuencode. In generale, qualsiasi output di GnuPG, cioè chiavi,
documenti cifrati e firme, possono essere ASCII-armored aggiungendo l’opzione --armor.
alice% gpg --armor --export [email protected]
-----BEGIN PGP PUBLIC KEY BLOCK-----
3
Capitolo 1. Incominciamo
[...]
-----END PGP PUBLIC KEY BLOCK-----
Una volta che la chiave è stata importata deve venir convalidata. GnuPG utilizza un potente e flessibile
modello basato sulla fiducia che non richiede all’utente di convalidare personalmente ogni chiave che
viene importata. Può comunque risultare necessaria la convalida personale di alcune chiavi. Una chiave
viene convalidata verificando l’impronta digitale6 della chiave stessa e successivamente firmando la
chiave per certificarla come chiave valida. L’impronta digitale di una chiave può essere velocemente
visualizzata con l’opzione a linea di comando --fingerprint, ma, allo scopo di certificare la chiave, è
necessario editarla.
alice% gpg --edit-key [email protected]
Comando> fpr
pub 1024D/9E98BC16 1999-06-04 Blake (esecutore) <[email protected]>
Impronta digitale: 268F 448F CCD7 AF34 183E 52D8 9BDE 1A08 9E98 BC16
L’impronta digitale di una chiave va verificata con il possessore di quella chiave. Ciò può essere fatto di
persona, per telefono o attraverso un qualsiasi altro mezzo con il quale sia possibile garantire che si sta
comunicando con il vero possessore della chiave. Se l’impronta digitale che si riceve è la stessa impronta
digitale che il possessore della chiave detiene, allora si può essere sicuri di possedere una corretta copia
della chiave.
Dopo aver controllato l’impronta digitale, si può procedere alla firma in modo da convalidarla. Poiché la
verifica di una chiave rappresenta un punto debole nella crittografia a chiave pubblica, è necessario
essere estremamente attenti è controllare sempre un’impronta digitale di una chiave con il possessore
prima di firmare la chiave stessa.
Comando> sign
4
Capitolo 1. Incominciamo
Firmo davvero?
Una volta firmato è possibile controllare la chiave listando le firme ad essa applicate e rilevare la firma
che si è appena aggiunta. Ogni User ID avrà sulla chiave una o più autofirme e una firma per ogni utente
che ha convalidato la chiave.
Comando> check
uid Blake (esecutore) <[email protected]>
sig! 9E98BC16 1999-06-04 [autofirma]
sig! BB7576AC 1999-06-04 Alice (giudice) <[email protected]>
L’opzione --recipient viene utilizzata una sola volta per ogni destinatario e richiede un argomento
extra che specifichi con quale chiave pubblica debba essere criptato il documento. Tale documento può
essere decriptato solo da qualcuno in possesso di una chiave privata che complementi una delle chiave
pubbliche dei destinatari. In particolare non è possibile decifrare un documento criptato da voi stessi, a
meno che non abbiate incluso la vostra chiave pubblica nella lista dei destinatari.
5
Capitolo 1. Incominciamo
Per decriptare un messaggio si usa l’opzione --decrypt. È necessario possedere la chiave privata con la
quale era stato cifrato il messaggio. Analogamente al processo di cifratura, il documento da decifrare è
l’ingresso e quello decifrato è l’uscita.
blake% gpg --output doc --decrypt doc.gpg
Inserisci la passphrase:
I documenti posso anche essere criptati senza l’utilizzo della crittografia a chiave pubblica. Al suo posto
è possibile utilizzare un algoritmo di crittografia simmetrico per cifrare il documento. La chiave fornita
all’algoritmo simmetrico viene derivata da una frase d’ordine fornita al momento in cui il documento
viene criptato e, per una buona sicurezza, non dovrebbe essere la stessa passphrase utilizzata per
proteggere la propria chiave privata. La cifratura simmetrica è utile per rendere sicuri i propri documenti
quando non è necessario comunicare ad altri la parola d’ordine utilizzata. Un documento può essere
criptato con un algoritmo simmetrico utilizzando l’opzione --symmetric.
alice% gpg --output doc.gpg --symmetric doc
Inserisci la passphrase:
6
Capitolo 1. Incominciamo
Inserisci la passphrase:
[...]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.7 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjdYCQoACgkQJ9S6ULt1dqz6IwCfQ7wP6i/i8HhbcOSKF4ELyQB1
oCoAoOuqpRqEzr4kOkQqHRLE/b8/Rw2k
=y6kj
-----END PGP SIGNATURE-----
7
Capitolo 1. Incominciamo
Inserisci la passphrase:
Sia il documento che la firma distaccata sono necessarie per verificare la firma stessa. L’opzione
--verify può essere utilizzata per controllare la firma.
Note
1. L’opzione 3 serve a generare una coppia di chiavi ElGamal che non è utilizzabile per fare firme.
2. D’ora in poi User ID per rispettare la traduzione del programma.
3. D’ora in poi passphrase come nel testo originale.
4. Numerose opzioni a linea di comando di uso frequente possono essere impostate in un file di
configurazione.
5. D’ora in poi ASCII-armored.
6. Si noti che qui l’aggettivo digitale può assumere due significati, entrambi validi. Il primo è quello
che deriva dalla traduzione della parola inglese originaria fingerprint, impronta delle dita. Il secondo
significato è quello di “prodotto con l’ausilio di un computer”, che è la macchina digitale per
eccellenza.
8
Capitolo 2. Concetti
GnuPG fa uso di diversi concetti di crittografia come algoritmi simmetrici, algoritmi a chiave pubblica, e
hashing a senso unico. È possibile utilizzare le funzioni di base di GnuPG senza comprendere appieno
tali concetti, ma, se si vuole usarlo con cognizione di causa, una loro comprensione è necessaria.
Questo capitolo introduce i concetti di base della crittografia utilizzati in GnuPG. Si possono trovare altri
libri che trattano questi argomenti più dettagliatamente. Un buon testo per approfondire ulteriormente gli
studi è “Applied Cryptography” (http://www.counterpane.com/applied.html) di Bruce Schneier
(http://www.counterpane.com/schneier.html).
9
Capitolo 2. Concetti
chiavi. Queste sono molte, molte di più e, anche se tutti i computer della terra cooperassero, sarebbe
ancora necessario più tempo di quello rappresentato dall’età dell’universo per trovare la chiave corretta.
10
Capitolo 2. Concetti
fondamentalmente differente a seconda dell’algoritmo che viene attaccato. Mentre 128 bit sono
sufficienti per un algoritmo simmetrico, data la tecnologia odierna di fattorizzazione, sono raccomandate
chiavi da 1024 bit per la maggior parte degli scopi.
11
Capitolo 2. Concetti
Un’alternativa consiste nel’utilizzare funzioni di hash pensate specificamente per soddisfare a queste due
importanti proprietà. SHA e MD5 sono due esempi di tali algoritmi. Utilizzando un algoritmo di questi,
un documento viene firmato applicando la funzione di hash ed il valore restituito rappresenta la firma.
Un’altra persona può controllare la firma applicando la stessa funzione di hash alla propria copia del
documento e confrontando il valore di hash ottenuto con quello del documento originale. Se coincidono,
può essere praticamente certo che i documenti sono identici.
Ovviamente ora il problema consiste nell’usare una funzione di hash per firme digitali senza permettere
ad un malintenzionato di interferire con il controllo della firma. Se documento e firma sono spediti in
chiaro, un malintenzionato potrebbe infatti modificare il documento e generare la corrispondente firma
senza che il destinatario ne venga a conoscenza. Se solo il documento è cifrato, un malintenzionato
potrebbe manomettere la firma e provocare un fallimento del controllo sulla firma. Una terza possibilità
consiste nell’usare una cifratura a chiave pubblica ibrida per criptare sia la firma che il documento. Il
firmatario usa la propria chiave privata e chiunque può adoperare la corrispondente chiave pubblica per
controllare la firma ed il documento. Quest’ultimo procedimento sembra corretto, ma in effetti non ha
senso. Se tale algoritmo mettesse veramente al sicuro il documento, esso sarebbe anche al sicuro da
eventuali manomissioni e non ci sarebbe bisogno di alcuna firma. Il problema più serio, comunque,
consiste nel fatto che tutto ciò non protegge da possibili manomissioni né la firma né il documento. Con
il nostro algoritmo, infatti, solo la chiave di sessione per l’algoritmo simmetrico viene criptata usando la
chiave privata del firmatario. Chiunque è in grado di usare la chiave pubblica per recuperare la chiave di
sessione. Perciò sarebbe banale per un malintenzionato recuperare tale chiave di sessione e usarla per
criptare documenti modificati e firme da spedire ad altri in nome del mittente.
Un algoritmo valido è quello che usa un algoritmo a chiave pubblica per cifrare solo la firma. In
particolare, il valore di hash viene criptato usando la chiave privata del firmatario permettendo a
chiunque di controllare la firma usando la corrispondente chiave pubblica. Il documento firmato può
essere spedito usando qualsiasi altro algoritmo di cifratura, compreso nessuno se si tratta di un
documento pubblico. Se il documento venisse modificato, il controllo della firma fallirebbe, ma ciò è
quello a cui serve il controllo della firma. Il Digital Signature Standard3 (DSA) è un algoritmo per la
firma a chiave pubblica che funziona come appena descritto. Il DSA è l’algoritmo principale usato da
GnuPG per firmare documenti.
Note
1. One-way trapdoor function nel testo originale. Qui il termine trapdoor potrebbe essere tradotto con
botola, scappatoia. Tali espressioni però non sono utilizzate nella pratica.
2. L’algoritmo deve possedere la proprietà che l’effettiva chiave pubblica o privata possa essere usata
dall’algoritmo di cifratura come chiave pubblica. L’RSA è un esempio di tale algoritmo, mentre
ElGamal non possiede tale proprietà.
3. Lo standard per la firma digitale.
12
Capitolo 3. Gestione delle chiavi
La manomissione delle chiavi è una delle principali debolezze per quanto concerne la sicurezza della
crittografia a chiave pubblica. Uno spione potrebbe manomettere il mazzo di chiavi di un utente o creare
la chiave pubblica di qualcuno e postarla affinché altri la scarichino e la utilizzino. Per esempio, si
supponga che Chloe voglia tenere sotto controllo i messaggi che Alice spedisce a Blake. Potrebbe
instaurare un attacco detto uomo nel mezzo. In questo tipo di attacco Chloe crea un nuova coppia di
chiavi pubblica/privata e rimpiazza la copia della chiave pubblica di Blake in possesso di Alice con la
nuova chiave pubblica. Successivamente si mette ad intercettare i messaggi che Alice spedisce a Blake.
Ogni messaggio intercettato viene decriptato utilizzando la nuova chiave privata e recriptato usando la
vera chiave pubblica di Blake, spedendo poi tale messaggio a Blake. Tutti i messaggi spediti da Alice a
Blake possono ora essere letti da Chloe.
Una buona gestione delle chiavi è cruciale se si desidera assicurare non solo l’integrità del proprio mazzo
di chiavi, ma anche l’integrità dei mazzi di chiavi di altri utenti. Il cuore della gestione delle chiavi
presente in GnuPG è la nozione di chiavi di firma1. La firma di una chiave ha due principali obiettivi:
permettere di rilevare eventuali manomissioni al proprio mazzo di chiavi e permettere di certificare che
una chiave appartenga veramente alla persona riportata dallo User ID della chiave. Le firme di una
chiave vengono anche usate in uno schema conosciuto come rete della fiducia, la quale estende la
certificazione delle chiavi non firmate di proprio pugno, ma da qualcun’altro di cui ci si fida. Utenti
responsabili che operano una buona gestione delle chiavi possono vanificare le manomissioni delle
chiavi praticate come attacco contro sistemi comunicazione sicura quali GnuPG.
La chiave pubblica viene visualizzata assieme ad un’indicazione circa la disponibilità di una chiave
privata. Quindi vengono listate le informazioni disponibili per ogni componente della chiave pubblica.
13
Capitolo 3. Gestione delle chiavi
La prima colonna indica il tipo di chiave. La parola pub sta ad indicare la chiave pubblica principale di
firma, mentre la parola sub sta ad indicare una chiave pubblica subordinata. La seconda colonna indica
la lunghezza della chiave in bit, il tipo e l’ID. Il tipo può essere D per una chiave DSA, g per una chiave
ElGamal di sola cifratura e G per una chiave ElGamal che può essere usata sia per cifrare che per firmare.
Le date di creazione e di scadenza sono date dalle colonne tre e quattro. Le chiavi sono seguite dagli
User ID.
Informazioni più dettagliate sulla chiave possono essere ottenute con comandi interattivi. Il comando
toggle commuta fra le componenti pubbliche e quelle private della coppia di chiavi se queste sono
effettivamente entrambi disponibili.
Comando> toggle
Le informazioni visualizzate sono simili a quelle fornite per la componente pubblica. La parola sec sta
ad indicare che la chiave è privata e di firma principale, mentre la parola sbb sta ad indicare che le chiavi
sono private e subordinate. Vengono listati per convenienza anche gli User ID della chiave pubblica.
14
Capitolo 3. Gestione delle chiavi
Comando> check
uid Chloe (giullare) <[email protected]>
sig! 26B6AAE1 1999-06-15 [autofirma]
uid Chloe (plebeo) <[email protected]>
sig! 26B6AAE1 1999-06-15 [autofirma]
Come ci si aspettava, la chiave di firma di ogni User ID è la chiave di firma principale con ID
0x26B6AAE1. Le autofirme delle sottochiavi sono presenti nella chiave pubblica, ma non vengono
mostrate dall’interfaccia di GnuPG.
15
Capitolo 3. Gestione delle chiavi
chiavi. Le componenti della chiave nuova e di quella vecchia vengono combinate nell’unione e questo
effettivamente ripristina ogni componente precedentemente cancellata. Per aggiornare nel modo corretto
la chiave, l’utente deve prima cancellare la vecchia copia della chiave pubblica e poi importare la nuova
versione. Ciò obera di ulteriore lavoro le persone con le quali si comunica. Inoltre, se si spedisce la
propria chiave ad un server di chiavi, l’unione avverrà in ogni caso e chiunque la scarichi non vedrà mai
le cancellazioni apportate. Di conseguenza, per aggiornare la propria chiave è meglio revocarne le
componenti al posto di cancellarle.
Uno User ID viene revocato in modo diverso. Normalmente uno User ID raccoglie le firme che attestano
che lo User ID descrive la persona che effettivamente possiede la chiave associata. In teoria uno User ID
descrive una persona per sempre in quanto quella persona non verrà mai cambiata. In pratica, invece, gli
elementi che compongono lo User ID, come l’indirizzo di posta elettronica e il commento, possono
cambiare nel tempo, così da invalidare lo User ID.
Le specifiche per l’OpenPGP
* Primo riferimento all’OpenPGP
non supportano la revoca dello User ID, ma in pratica ciò può essere fatto revocando l’autofirma che
accompagna lo User ID. Per i motivi di sicurezza descritti precedentemente, gli altri corrispondenti non
si fideranno di uno User ID senza una valida autofirma.
Una firma è revocata mediante il comando revsig. Poiché è possibile aver firmato un numero qualsiasi di
User ID, l’interfaccia utente richiederà di decidere per ogni firma se essa debba essere revocata o meno.
Comando> revsig
Hai firmato questi user ID:
Chloe (giullare) <[email protected]>
signed by B87DBA93 at 1999-06-28
Chloe (plebeo) <[email protected]>
signed by B87DBA93 at 1999-06-28
user ID: "Chloe (giullare) <[email protected]>"
firmata con la tua chiave B87DBA93 il 1999-06-28
16
Capitolo 3. Gestione delle chiavi
Uno User ID revocato viene indicato dalla firma di revoca che accompagna lo User ID quando vengono
listate le firme degli User ID delle chiavi.
Comando> check
uid Chloe (giullare) <[email protected]>
sig! B87DBA93 1999-06-28 [autofirma]
uid Chloe (plebeo) <[email protected]>
rev! B87DBA93 1999-06-29 [revoca]
sig! B87DBA93 1999-06-28 [autofirma]
Revocando sia le sottochiavi che le autofirme di uno User ID si aggiungono delle autofirme di revoca alla
chiave. Poiché le firme vengono aggiunte e nulla viene cancellato, una revoca sarà sempre visibile agli
altri quando la propria chiave aggiornata verrà distribuita e unita con le copie precedenti. La revoca,
quindi, garantisce che chiunque avrà una copia consistente della vostra chiave.
17
Capitolo 3. Gestione delle chiavi
sconosciuto
Non c’è nessuna informazione sul giudizio del possessore nella chiave di firma. Le chiavi del
proprio mazzo che non siano le proprie hanno inizialmente questo livello di fiducia.
nessuna
Si sa che il possessore non firma opportunamente le chiavi degli altri.
marginale
Il possessore capisce le implicazioni che comporta firmare una chiave ed è capace di convalidare le
chiavi propriamente prima di firmarle.
18
Capitolo 3. Gestione delle chiavi
piena
Il possessore ha un’eccellente comprensione di ciò che comporta firmare una chiave e la sua firma
su una chiave è tanto valida quanto la propria.
Un livello di fiducia per la chiave è qualcosa che si assegna da soli alla chiave ed è considerata
un’informazione privata. Non viene inclusa con la chiave quando questa è esportata; viene perfino
salvata separatamente dal proprio mazzo di chiavi in un elenco a sé stante.
L’editor delle chiavi di GnuPG può essere usato per impostare la fiducia che si possiede verso il
possessore di una chiave. Il comando è trust. In questo esempio Alice modifica la propria fiducia verso
Blake e quindi aggiorna il database della fiducia per ricalcolare quali chiavi siano valide con questa sua
nuova fiducia verso Blake.
alice% gpg --edit-key blake
Comando> trust
pub 1024D/8B927C8A creata il: 1999-07-02 scade: mai fiducia: q/f
sub 1024g/C19EA233 creata il: 1999-07-02 scade: mai
(1) Blake (esecutore) <[email protected]>
Per favore, decidi quanta fiducia hai che questo utente verifichi
correttamente le chiavi di altri utenti (guardando il loro passaporto,
controllando le impronte digitali prese da diverse fonti, etc.)?
1 = Non lo so
2 = NON mi fido
3 = Mi fido marginalmente
4 = Mi fido completamente
s = mostrami ulteriori informazioni
m = torna al menù principale
Comando> quit
[...]
La fiducia nel possessore della chiave e la validità della chiave sono indicate sulla destra quando viene
mostrata la chiave. Prima viene la fiducia nella persona e poi la validità della chiave4. I quattro livelli di
fiducia/validità sono abbreviati con: sconosciuto (q), nessuna (n), marginale (m) e piena (f). In questo
caso la chiave di Blake è pienamente valida in quanto è stata Alice stessa a firmarla. Inizialmente Alice
ha una fiducia non nota nella capacità di Blake di firmare altre chiavi, ma decide di concedergli una
fiducia marginale.
19
Capitolo 3. Gestione delle chiavi
20
Capitolo 3. Gestione delle chiavi
pagare, ovviamente, consiste nel fatto che è più difficile convalidare le chiavi in quanto è necessario
firmare personalmente più chiavi di quante ne sarebbero necessarie se si accettassero percorsi più brevi
ed in numero inferiore.
fiducia validità
marginale piena marginale piena
Dharma Blake, Chloe, Dharma,
Francis
Blake, Dharma Francis Blake, Chloe, Dharma
Chloe, Dharma Chloe, Francis Blake, Dharma
Blake, Chloe, Dharma Elena Blake, Chloe, Dharma,
Francis
Blake, Chloe, Elena Blake, Chloe, Elena,
Francis
21
Capitolo 3. Gestione delle chiavi
Blake verso la comunità intera mantenere una stretta rete di fiducia e migliorare così la sicurezza di
GnuPG. Questo meccanismo può diventare fastidioso se la firma di chiavi avviene con frequenza.
L’uso di un server di chiavi rende il processo in qualche modo più semplice. Dopo che Blake ha firmato
la chiave di Alice, egli la invia al server di chiavi. Il server aggiunge la firma di Blake alla copia della
chiave di Alice in suo possesso. Le persone interessate nell’aggiornare la propria copia della chiave di
Alice possono quindi consultare di propria iniziativa il server ed ottenere la chiave aggiornata. Non c’è
bisogno che Alice venga coinvolta nella distribuzione e, per aggiornare la sua chiave, può semplicemente
prelevare le nuove firme apposte interrogando il server.
* --keyserver deve venire prima dell’opzione --send-key o --recv-key . Questo sembra essere un baco.
È possibile spedire una o più chiavi ad un server utilizzando l’opzione a linea di comando
--send-keys. L’opzione richiede uno o più specificatori di chiave e la sua azione consiste nello spedire
le chiavi indicate al server di chiavi. Il server al quale inviare le chiavi è specificato con l’opzione a linea
di comando --keyserver. In modo analogo l’opzione --recv-keys viene usata per ottenere delle
chiavi da un server, ma l’opzione --recv-keys richede che venga specificato un ID di chiave. Nel
seguente esempio Alice aggiorna la propria chiave con le nuove firme dal server di chiavi
certserver.pgp.com e successivamente spedisce la propria copia della chiave pubblica di Blake
allo stesso server per contribuire con una qualche nuova firma che potrebbe aver aggiunto.
alice% gpg --keyserver certserver.pgp.com --recv-key 0xBB7576AC
gpg: richiesta chiave BB7576AC da certserver.pgp.com ...
gpg: chiave BB7576AC: 1 nuova firma
Esistono diversi server di chiavi in uso in giro per il mondo. I server principali si sincronizzano a vicenda
cosicché è sufficiente scegliere quello più vicino ed usarlo regolarmente per spedire e ricevere chiavi.
Note
1. Dal testo originale signing key. Una chiave di firma è quel tipo chiave che può essere usata per
apporre una firma.
2. Self-signing nel testo originale.
3. Web of trust nel testo originale.
4. GnuPG estende il significato della parola “fiducia” intendendola come la fiducia riposta in una
persona e quella riposta in una chiave. Ciò può essere fonte di confusione. A volte ci si riferisce alla
fiducia in un possessore, usando esplicitamente fiducia nel possessore, per distringuerla dalla fiducia
in una chiave. In questo manuale, comunque, “fiducia” è usato per indicare la fiducia nel possessore
di una chiave e “validità” per indicare la fiducia che si possiede nel fatto che una chiave appartenga
ad un essere umano associato all’ID della chiave.
22
Capitolo 4. Uso quotidiano di GnuPG
GnuPG è uno strumento complesso che coinvolge questioni tecniche, sociali e legali. Da un punto di
vista tecnico è stato progettato per venir usato in situazioni con requisiti di sicurezza notevolmente
differenti, fatto che ha complicato la gestione delle chiavi. Da un punto di vista sociale, l’uso di GnuPG
non è una decisione strettamente personale. Per utilizzare veramente GnuPG entrambe le parti coinvolte
nella comunicazione devono usarlo effettivamente. Infine, a partire all’incirca dal 1999, le leggi
riguardanti la criptazione digitale, in particolare la legalità dell’uso di GnuPG, variano da stato a stato e
sono tutt’ora dibattute dai governi di molte nazioni.
Il presente capitolo affronta queste tematiche. Esso fornisce pratici consigli su come usare GnuPG per
soddisfare alle proprie esigenze di sicurezza. Suggerisce anche dei modi per promuovere l’uso di GnuPG
come strumento per comunicazioni sicure fra sé ed i propri colleghi, quando questi non lo utilizzano già.
Infine, viene sottolineato lo status legale di GnuPG all’interno dello stato corrente delle leggi sulla
criptazione nel mondo.
• la scelta della dimensione della chiave della propria coppia di chiavi pubblica/privata,
• la protezione della propria chiave privata,
• la scelta delle date di scadenza e dell’uso di sottochiavi e
• la gestione della propria rete della fiducia.
Una dimensione della chiave scelta bene protegge dagli attacchi a forza bruta sferrati contro i messaggi
criptati. Proteggere la propria chiave privata evita che un malintenzionato possa semplicemente usare la
propria chiave privata per decifrare messaggi criptati e firmare messaggi a vostro nome. La corretta
gestione della propria rete della fiducia evita che dei malintenzionati fingano di essere le persone con le
quali usualmente si comunica. Infine, decidere per questi elementi di personalizzazione rispettando i
propri requisiti di sicurezza è il modo in cui si bilancia il lavoro extra dovuto all’uso di GnuPG con la
privacy che esso offre.
23
Capitolo 4. Uso quotidiano di GnuPG
preimpostati per la generazione di chiavi con GnuPG, la chiave principale sarà di tipo DSA e le
sotto-chiavi di tipo ElGamal.
Per lo standard DSA sono previste chiavi fino a 1024 bit. Questo valore non è particolarmente alto data la
tecnologia di fattorizzazione di oggi, ma è ciò che lo standard specifica. Senza esitazioni si dovrebbero
quindi usare chiavi DSA da 1024 bit.
Le chiavi ElGamal, d’altro canto, possono essere di qualsiasi dimensione. Poiché GnuPG è un sistema a
chiave pubblica ibrido, la chiave pubblica viene usata per criptare una chiave di sessione da 128 bit,
mentre la chiave privata è usata per decriptarla. Ciò nonostante, la dimensione della chiave influenza la
velocità di cifratura e decifratura in quanto il costo di questi algoritmi cresce esponenzialmente con il
crescere della dimensione della chiave. Chiavi grandi, inoltre, richiedono più tempo ad essere generate e
più spazio per essere salvate. Infine, c’è una riduzione del ritorno di sicurezza che una chiave grande
fornisce. Dopo tutto, se la chiave è tanto grande da resistere ad un attacco a forza bruta, uno spione
semplicemente cambierebbe metodo e cercherebbe di ottenere i dati in chiaro in un altro modo. Esempi
di tali metodi alternativi sono il furto in appartamento e la rapina. 1024 bit è perciò la dimensione di
chiave raccomandata. Se si ha sinceramente bisogno di una dimensione di chiave maggiore, allora
probabilmente si conoscono già tutte queste problematiche e ci si dovrebbe rivolgere pertanto ad un
esperto in sicurezza di dati.
24
Capitolo 4. Uso quotidiano di GnuPG
Tutto questo non significa che non si possa o non si debba usare GnuPG. Piuttosto si è deciso che i dati
da proteggere sono abbastanza importanti da venir cifrati, ma non così importanti da richiedere un
impegno ulteriore affinché la prima barriera risulti più robusta. È una questione di scelta.
Una buona passphrase è assolutamente cruciale nell’uso di GnuPG. Qualsiasi malintenzionato che riesca
a guadagnare l’accesso alla propria chiave privata deve oltrepassare la cifratura della chiave privata
stessa. Invece di indovinare brutalmente la chiave, il malintenzionato cercherà quasi certamente di
indovinare la passphrase.
Il motivo per cui si prova prima con la passphrase consiste nel fatto che la maggior parte delle persone
sceglie una passphrase più facile da indovinare di una chiave casuale a 128 bit. Se la passphrase è una
parola, è molto più economico provare tutte le parole presenti nei dizionari delle lingue del mondo.
Anche se i caratteri della parola sono permutati, per esempio “putcomter” invece di “computer”, è
comunque più semplice provare con delle parole da dizionario a cui sono applicate delle regole di
permutazione. Lo stesso problema si applica a citazioni. Generalmente le passphrase basate su frasi del
linguaggio naturale sono poveri esempi di passphrase, in quanto esiste poca casualità e molta ridondanza
nel linguaggio naturale.
Una buona passphrase è quella passphrase che si riesce a ricordare, ma che altri difficilmente possono
indovinare. Essa dovrebbe includere caratteri presi da tutto lo spettro dei caratteri stampabili presenti
sulla tastiera. Ciò include i caratteri alfabetici maiuscoli, numeri e caratteri speciali come } e |. Bisonga
essere creativi e spendere un po’ di tempo nel considerare la propria passphrase; una buona scelta è
importante per assicurare la propria privacy.
25
Capitolo 4. Uso quotidiano di GnuPG
altre firme in quanto la nuova sotto-chiave sarà stata firmata mediante la vostra chiave di firma
principale, la quale, verosimilmente, è già stata convalidata dai vostri corrispondenti.
Questa sconvenienza può o meno valere la sicurezza aggiunta. Proprio come è possibile fare di persona,
un malintenzionato può tuttavia leggere tutti i documenti criptati con la sotto-chiave scaduta [se riuscisse
ad entrarne in possesso, ndt]. Cambiare le sotto-chiavi protegge solo i documenti futuri. Per leggere i
documenti cifrati con la nuova sotto-chiave, un malintenzionato avrebbe bisogno di cominciare un nuovo
attacco utilizzando una qualsiasi delle tecniche adottate la prima volta nei vostri confronti.
Per concludere, ha senso avere solo una sotto-chiave di cifratura valida in un mazzo. Non c’è nessun
guadagno in termini di sicurezza nell’avere due o più sotto-chiavi attive. Può certamente esserci un
numero qualsiasi di chiavi scadute in un mazzo, in modo tale che documenti cifrati in passato possano
ancora essere decifrati, ma è sufficiente che solo una sotto-chiave sia attiva in un dato momento.
26
Capitolo 4. Uso quotidiano di GnuPG
27
Capitolo 4. Uso quotidiano di GnuPG
Note
1. In questa sezione GnuPG si riferisce tanto all’implementazione GnuPG di OpenPGP quanto ad altre
implementazioni, come PGP prodotto della NAI.
28
Capitolo 5. Argomenti vari
Questo capitolo riguarda argomenti disparati che non hanno trovato posto in altre parti di questo
manuale. Quando verranno aggiunti ulteriori paragrafi, essi potrebbero venir raccolti e ripartiti in capitoli
a sé stanti. Se si desidera venga trattato un particolare argomento, si prega di mandare un suggerimento o,
ancora meglio, si potrebbe volontariamente scrivere una prima bozza riguardante l’argomento suggerito!
29
Capitolo 5. Argomenti vari
corretto modello della relazione fra chiavi pubbliche e private e una chiara comprensione delle
funzioni per l’acquisizione e la distribuzione delle chiavi.
La progettazione di un’interfaccia utente efficace per la gestione delle chiavi è ancora più complicata. Il
modello della rete della fiducia di OpenPGP è sfortunatamente alquanto ottuso. Per esempio, le
specifiche impongono tre livelli arbitrari di fiducia per l’utente: nessuno, marginale e completo. Tutti i
gradi di fiducia percepiti dall’utente devono ricadere all’interno di uno di questi tre angusti livelli.
L’algoritmo di convalida delle chiavi risulta inoltre difficile da comprendere per chi non è un
appassionato di computer, in particolare le nozioni di “necessità marginale” e “necessità completa”.
Poiché il modello della rete della fiducia è ben specificato e non può essere modificato, sarà necessario
fare del proprio meglio per progettare un’interfaccia utente che aiuti a chiarificare tale modello
all’utente. Un sicuro miglioramente, per esempio, si otterrebbe nel generare un diagramma che
rappresenti come una chiave è stata validata al momento della richiesta da parte dell’utente. Tra i
commenti di un certo rilievo derivanti dal rapporto sono inclusi quelli riportati qui di seguito.
• Gli utenti sono spesso incerti su come e quanto garantire gli accessi.
• Si dia alta priorità nell’assicurarsi che gli utenti capiscano sufficientemente la loro sicurezza in modo
da evitare che commettano errori potenzialmente costosi. Questa categoria di errori include la
cancellazione accidentale della chiave privata, la pubblicazione accidentale di una chiave, la revoca
accidentale di una chiave, il dimenticarsi della passphrase ed il fallimento nell’effettuare una copia di
sicurezza del mazzo di chiavi.
30
Appendice A. GNU Free Documentation
License
Version 1.1, March 2000
Copyright (C) 2000 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not
allowed.
0. PREAMBLE
The purpose of this License is to make a manual, textbook, or other written document "free" in the sense
of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without
modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author
and publisher a way to get credit for their work, while not being considered responsible for modifications
made by others.
This License is a kind of "copyleft", which means that derivative works of the document must themselves
be free in the same sense. It complements the GNU General Public License, which is a copyleft license
designed for free software.
We have designed this License in order to use it for manuals for free software, because free software
needs free documentation: a free program should come with manuals providing the same freedoms that
the software does. But this License is not limited to software manuals; it can be used for any textual
work, regardless of subject matter or whether it is published as a printed book. We recommend this
License principally for works whose purpose is instruction or reference.
31
Appendice A. GNU Free Documentation License
The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover
Texts, in the notice that says that the Document is released under this License.
A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose
specification is available to the general public, whose contents can be viewed and edited directly and
straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or
(for drawings) some widely available drawing editor, and that is suitable for input to text formatters or
for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an
otherwise Transparent file format whose markup has been designed to thwart or discourage subsequent
modification by readers is not Transparent. A copy that is not "Transparent" is called "Opaque".
Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input
format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming
simple HTML designed for human modification. Opaque formats include PostScript, PDF, proprietary
formats that can be read and edited only by proprietary word processors, SGML or XML for which the
DTD and/or processing tools are not generally available, and the machine-generated HTML produced by
some word processors for output purposes only.
The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed
to hold, legibly, the material this License requires to appear in the title page. For works in formats which
do not have any title page as such, "Title Page" means the text near the most prominent appearance of the
work’s title, preceding the beginning of the body of the text.
2. VERBATIM COPYING
You may copy and distribute the Document in any medium, either commercially or noncommercially,
provided that this License, the copyright notices, and the license notice saying this License applies to the
Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this
License. You may not use technical measures to obstruct or control the reading or further copying of the
copies you make or distribute. However, you may accept compensation in exchange for copies. If you
distribute a large enough number of copies you must also follow the conditions in section 3.
You may also lend copies, under the same conditions stated above, and you may publicly display copies.
3. COPYING IN QUANTITY
If you publish printed copies of the Document numbering more than 100, and the Document’s license
notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all
these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both
covers must also clearly and legibly identify you as the publisher of these copies. The front cover must
present the full title with all words of the title equally prominent and visible. You may add other material
on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of
the Document and satisfy these conditions, can be treated as verbatim copying in other respects.
If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed
(as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering more than 100, you must either
include a machine-readable Transparent copy along with each Opaque copy, or state in or with each
32
Appendice A. GNU Free Documentation License
4. MODIFICATIONS
You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and
3 above, provided that you release the Modified Version under precisely this License, with the Modified
Version filling the role of the Document, thus licensing distribution and modification of the Modified
Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:
A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from
those of previous versions (which should, if there were any, be listed in the History section of the
Document). You may use the same title as a previous version if the original publisher of that version
gives permission.
B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the
modifications in the Modified Version, together with at least five of the principal authors of the
Document (all of its principal authors, if it has less than five).
C. State on the Title page the name of the publisher of the Modified Version, as the publisher.
D. Preserve all the copyright notices of the Document.
E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.
F. Include, immediately after the copyright notices, a license notice giving the public permission to use
the Modified Version under the terms of this License, in the form shown in the Addendum below.
G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in
the Document’s license notice.
H. Include an unaltered copy of this License.
I. Preserve the section entitled "History", and its title, and add to it an item stating at least the title,
year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no
section entitled "History" in the Document, create one stating the title, year, authors, and publisher
of the Document as given on its Title Page, then add an item describing the Modified Version as
stated in the previous sentence.
J. Preserve the network location, if any, given in the Document for public access to a Transparent copy
of the Document, and likewise the network locations given in the Document for previous versions it
was based on. These may be placed in the "History" section. You may omit a network location for a
work that was published at least four years before the Document itself, or if the original publisher of
the version it refers to gives permission.
33
Appendice A. GNU Free Documentation License
K. In any section entitled "Acknowledgements" or "Dedications", preserve the section’s title, and
preserve in the section all the substance and tone of each of the contributor acknowledgements
and/or dedications given therein.
L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section
numbers or the equivalent are not considered part of the section titles.
M. Delete any section entitled "Endorsements". Such a section may not be included in the Modified
Version.
N. Do not retitle any existing section as "Endorsements" or to conflict in title with any Invariant Section.
If the Modified Version includes new front-matter sections or appendices that qualify as Secondary
Sections and contain no material copied from the Document, you may at your option designate some or
all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the
Modified Version’s license notice. These titles must be distinct from any other section titles.
You may add a section entitled "Endorsements", provided it contains nothing but endorsements of your
Modified Version by various parties--for example, statements of peer review or that the text has been
approved by an organization as the authoritative definition of a standard.
You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a
Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of
Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any
one entity. If the Document already includes a cover text for the same cover, previously added by you or
by arrangement made by the same entity you are acting on behalf of, you may not add another; but you
may replace the old one, on explicit permission from the previous publisher that added the old one.
The author(s) and publisher(s) of the Document do not by this License give permission to use their
names for publicity for or to assert or imply endorsement of any Modified Version.
5. COMBINING DOCUMENTS
You may combine the Document with other documents released under this License, under the terms
defined in section 4 above for modified versions, provided that you include in the combination all of the
Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of
your combined work in its license notice.
The combined work need only contain one copy of this License, and multiple identical Invariant Sections
may be replaced with a single copy. If there are multiple Invariant Sections with the same name but
different contents, make the title of each such section unique by adding at the end of it, in parentheses,
the name of the original author or publisher of that section if known, or else a unique number. Make the
same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined
work.
In the combination, you must combine any sections entitled "History" in the various original documents,
forming one section entitled "History"; likewise combine any sections entitled "Acknowledgements",
and any sections entitled "Dedications". You must delete all sections entitled "Endorsements."
34
Appendice A. GNU Free Documentation License
6. COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other documents released under this License,
and replace the individual copies of this License in the various documents with a single copy that is
included in the collection, provided that you follow the rules of this License for verbatim copying of each
of the documents in all other respects.
You may extract a single document from such a collection, and distribute it individually under this
License, provided you insert a copy of this License into the extracted document, and follow this License
in all other respects regarding verbatim copying of that document.
8. TRANSLATION
Translation is considered a kind of modification, so you may distribute translations of the Document
under the terms of section 4. Replacing Invariant Sections with translations requires special permission
from their copyright holders, but you may include translations of some or all Invariant Sections in
addition to the original versions of these Invariant Sections. You may include a translation of this License
provided that you also include the original English version of this License. In case of a disagreement
between the translation and the original English version of this License, the original English version will
prevail.
9. TERMINATION
You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under
this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will
automatically terminate your rights under this License. However, parties who have received copies, or
rights, from you under this License will not have their licenses terminated so long as such parties remain
in full compliance.
35
Appendice A. GNU Free Documentation License
Copyright (c) YEAR YOUR NAME. Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the
Free Software Foundation; with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts
being LIST, and with the Back-Cover Texts being LIST. A copy of the license is included in the section entitled
"GNU Free Documentation License".
If you have no Invariant Sections, write "with no Invariant Sections" instead of saying which ones are
invariant. If you have no Front-Cover Texts, write "no Front-Cover Texts" instead of "Front-Cover Texts
being LIST"; likewise for Back-Cover Texts.
If your document contains nontrivial examples of program code, we recommend releasing these
examples in parallel under your choice of free software license, such as the GNU General Public
License, to permit their use in free software.
36
Appendice B. GNU Free Documentation
License (traduzione italiana)
Questa è semplicemente una traduzione della licenza che accompagna questo documento, e non ha
valore legale. Riferirsi alla versione originale in lingua inglese, acclusa in questo documento, per ogni
questione di rilievo.
Versione 1.1, Marzo 2000
Copyright © 2000
Chiunque può copiare e distribuire copie letterali di questo documento di licenza, ma non ne è permessa
la modifica.
0. PREAMBOLO
Lo scopo di questa licenza è di rendere un manuale, un testo o altri documenti scritti "liberi" nel senso di
assicurare a tutti la libertà effettiva di copiarli e redistribuirli, con o senza modifiche, a fini di lucro o no.
In secondo luogo questa licenza prevede per autori ed editori il modo per ottenere il giusto
riconoscimento del proprio lavoro, preservandoli dall’essere considerati responsabili per modifiche
apportate da altri.
Questa licenza è un "copyleft": ciò vuol dire che i lavori che derivano dal documento originale devono
essere ugualmente liberi. È il complemento alla GNU General Public License, che è una licenza di tipo
"copyleft" pensata per il software libero.
Abbiamo progettato questa licenza al fine di applicarla alla documentazione del software libero, perché il
software libero ha bisogno di documentazione libera: un programma libero dovrebbe accompagnarsi a
manuali che forniscano la stessa libertà del software. Ma questa licenza non è limitata alla
documentazione del software; può essere utilizzata per ogni testo che tratti un qualsiasi argomento e al di
là dell’avvenuta pubblicazione cartacea. Raccomandiamo principalmente questa licenza per opere che
abbiano fini didattici o per manuali di consultazione.
1. APPLICABILITÀ E DEFINIZIONI
Questa licenza si applica a qualsiasi manuale o altra opera che contenga una nota messa dal detentore del
copyright che dica che si può distribuire nei termini di questa licenza. Con "Documento", in seguito ci si
riferisce a qualsiasi manuale o opera. Ogni fruitore è un destinatario della licenza e viene indicato con
"voi".
Una "versione modificata" di un documento è ogni opera contenente il documento stesso o parte di esso,
sia riprodotto alla lettera che con modifiche, oppure traduzioni in un’altra lingua.
37
Appendice B. GNU Free Documentation License (traduzione italiana)
Una "sezione secondaria" è un’appendice cui si fa riferimento o una premessa del documento e riguarda
esclusivamente il rapporto dell’editore o dell’autore del documento con l’argomento generale del
documento stesso (o argomenti affini) e non contiene nulla che possa essere compreso nell’argomento
principale. (Per esempio, se il documento è in parte un manuale di matematica, una sezione secondaria
non può contenere spiegazioni di matematica). Il rapporto con l’argomento può essere un tema collegato
storicamente con il soggetto principale o con soggetti affini, o essere costituito da argomentazioni legali,
commerciali, filosofiche, etiche o politiche pertinenti.
Le "sezioni non modificabili" sono alcune sezioni secondarie i cui titoli sono esplicitamente dichiarati
essere sezioni non modificabili, nella nota che indica che il documento è realizzato sotto questa licenza.
I "testi copertina" sono dei brevi brani di testo che sono elencati nella nota che indica che il documento è
realizzato sotto questa licenza.
Una copia "trasparente" del documento indica una copia leggibile da un calcolatore, codificata in un
formato le cui specifiche sono disponibili pubblicamente, i cui contenuti possono essere visti e modificati
direttamente, ora e in futuro, con generici editor di testi o (per immagini composte da pixel) con generici
editor di immagini o (per i disegni) con qualche editor di disegni ampiamente diffuso, e la copia deve
essere adatta al trattamento per la formattazione o per la conversione in una varietà di formati atti alla
successiva formattazione. Una copia fatta in un altro formato di file trasparente il cui markup è stato
progettato per intralciare o scoraggiare modifiche future da parte dei lettori non è trasparente. Una copia
che non è trasparente è "opaca".
Esempi di formati adatti per copie trasparenti sono l’ASCII puro senza markup, il formato di input per
Texinfo, il formato di input per LaTex, SGML o XML accoppiati ad una DTD pubblica e disponibile, e
semplice HTML conforme agli standard e progettato per essere modificato manualmente. Formati opachi
sono PostScript, PDF, formati proprietari che possono essere letti e modificati solo con word processor
proprietari, SGML o XML per cui non è in genere disponibile la DTD o gli strumenti per il trattamento,
e HTML generato automaticamente da qualche word processor per il solo output.
La "pagina del titolo" di un libro stampato indica la pagina del titolo stessa, più qualche pagina seguente
per quanto necessario a contenere in modo leggibile, il materiale che la licenza prevede che compaia
nella pagina del titolo. Per opere in formati in cui non sia contemplata esplicitamente la pagina del titolo,
con "pagina del titolo" si intende il testo prossimo al titolo dell’opera, precedente l’inizio del corpo del
testo.
38
Appendice B. GNU Free Documentation License (traduzione italiana)
4. MODIFICHE
Si possono copiare e distribuire versioni modificate del documento rispettando le condizioni delle
precedenti sezioni 2 e 3, purché la versione modificata sia realizzata seguendo scrupolosamente questa
stessa licenza, con la versione modificata che svolga il ruolo del "documento", così da estendere la
licenza sulla distribuzione e la modifica a chiunque ne possieda una copia. Inoltre nelle versioni
modificate si deve:
A. Usare nella pagina del titolo (e nelle copertine se ce ne sono) un titolo diverso da quello del
documento, e da quelli di versioni precedenti (che devono essere elencati nella sezione storia del
documento ove presenti). Si può usare lo stesso titolo di una versione precedente se l’editore di
quella versione originale ne ha dato il permesso.
B. Elencare nella pagina del titolo, come autori, una o più persone o gruppi responsabili in qualità di
autori delle modifiche nella versione modificata, insieme ad almeno cinque fra i principali autori del
documento (tutti gli autori principali se sono meno di cinque).
C. Dichiarare nella pagina del titolo il nome dell’editore della versione modificata in qualità di editore.
D. Conservare tutte le note sul copyright del documento originale.
E. Aggiungere un’appropriata licenza per le modifiche di seguito alle altre licenze sui copyright.
39
Appendice B. GNU Free Documentation License (traduzione italiana)
F. Includere immediatamente dopo la nota di copyright, un avviso di licenza che dia pubblicamente il
permesso di usare la versione modificata nei termini di questa licenza, nella forma mostrata
nell’addendum alla fine di questo testo.
G. Preservare in questo avviso di licenza l’intera lista di sezioni non modificabili e testi copertina
richieste come previsto dalla licenza del documento.
H. Includere una copia non modificata di questa licenza.
I. Conservare la sezione intitolata "Storia", e il suo titolo, e aggiungere a questa un elemento che
riporti al minimo il titolo, l’anno, i nuovi autori, e gli editori della versione modificata come figurano
nella pagina del titolo. Se non ci sono sezioni intitolate "Storia" nel documento, createne una che
riporti il titolo, gli autori, gli editori del documento come figurano nella pagina del titolo, quindi
aggiungete un elemento che descriva la versione modificata come detto in precedenza.
J. Conservare l’indirizzo in rete riportato nel documento, se c’è, al fine del pubblico accesso ad una
copia trasparente, e possibilmente l’indirizzo in rete per le precedenti versioni su cui ci si è basati.
Questi possono essere collocati nella sezione "Storia". Si può omettere un indirizzo di rete per
un’opera pubblicata almeno quattro anni prima del documento stesso, o se l’originario editore della
versione cui ci si riferisce ne dà il permesso.
K. In ogni sezione di "Ringraziamenti" o "Dediche", si conservino il titolo, il senso, il tono della
sezione stessa.
L. Si conservino inalterate le sezioni non modificabili del documento, nei propri testi e nei propri titoli.
I numeri della sezione o equivalenti non sono considerati parte del titolo della sezione.
M. Si cancelli ogni sezione intitolata "Riconoscimenti". Solo questa sezione può non essere inclusa
nella versione modificata.
N. Non si modifichi il titolo di sezioni esistenti come "miglioria" o per creare confusione con i titoli di
sezioni non modificabili.
Se la versione modificata comprende nuove sezioni di primaria importanza o appendici che ricadono in
"sezioni secondarie", e non contengono materiale copiato dal documento, si ha facoltà di rendere non
modificabili quante sezioni si voglia. Per fare ciò si aggiunga il loro titolo alla lista delle sezioni
immutabili nella nota di copyright della versione modificata. Questi titoli devono essere diversi dai titoli
di ogni altra sezione.
Si può aggiungere una sezione intitolata "Riconoscimenti", a patto che non contenga altro che le
approvazioni alla versione modificata prodotte da vari soggetti--per esempio, affermazioni di revisione o
che il testo è stato approvato da una organizzazione come la definizione normativa di uno standard.
Si può aggiungere un brano fino a cinque parole come Testo Copertina, e un brano fino a 25 parole come
Testo di Retro Copertina, alla fine dell’elenco dei Testi Copertina nella versione modificata. Solamente
un brano del Testo Copertina e uno del Testo di Retro Copertina possono essere aggiunti (anche con
adattamenti) da ciascuna persona o organizzazione. Se il documento include già un testo copertina per la
stessa copertina, precedentemente aggiunto o adattato da voi o dalla stessa organizzazione nel nome della
quale si agisce, non se ne può aggiungere un altro, ma si può rimpiazzare il vecchio ottenendo l’esplicita
autorizzazione dall’editore precedente che aveva aggiunto il testo copertina.
L’autore/i e l’editore/i del "documento" non ottengono da questa licenza il permesso di usare i propri
nomi per pubblicizzare la versione modificata o rivendicare l’approvazione di ogni versione modificata.
40
Appendice B. GNU Free Documentation License (traduzione italiana)
5. UNIONE DI DOCUMENTI
Si può unire il documento con altri realizzati sotto questa licenza, seguendo i termini definiti nella
precedente sezione 4 per le versioni modificate, a patto che si includa l’insieme di tutte le Sezioni
Invarianti di tutti i documenti originali, senza modifiche, e si elenchino tutte come Sezioni Invarianti
della sintesi di documenti nella licenza della stessa.
Nella sintesi è necessaria una sola copia di questa licenza, e multiple sezioni invarianti possono essere
rimpiazzate da una singola copia se identiche. Se ci sono multiple Sezioni Invarianti con lo stesso nome
ma contenuti differenti, si renda unico il titolo di ciascuna sezione aggiungendovi alla fine e fra
parentesi, il nome dell’autore o editore della sezione, se noti, o altrimenti un numero distintivo. Si
facciano gli stessi aggiustamenti ai titoli delle sezioni nell’elenco delle Sezioni Invarianti nella nota di
copiright della sintesi.
Nella sintesi si devono unire le varie sezioni intitolate "storia" nei vari documenti originali di partenza
per formare una unica sezione intitolata "storia"; allo stesso modo si unisca ogni sezione intitolata
"Ringraziamenti", e ogni sezione intitolata "Dediche". Si devono eliminare tutte le sezioni intitolate
"Riconoscimenti".
6. RACCOLTE DI DOCUMENTI
Si può produrre una raccolta che consista del documento e di altri realizzati sotto questa licenza; e
rimpiazzare le singole copie di questa licenza nei vari documenti con una sola inclusa nella raccolta,
solamente se si seguono le regole fissate da questa licenza per le copie alla lettera come se si applicassero
a ciascun documento.
Si può estrarre un singolo documento da una raccolta e distribuirlo individualmente sotto questa licenza,
solo se si inserisce una copia di questa licenza nel documento estratto e se si seguono tutte le altre regole
fissate da questa licenza per le copie alla lettera del documento.
8. TRADUZIONI
La traduzione è considerata un tipo di modifica, e di conseguenza si possono distribuire traduzioni del
documento seguendo i termini della sezione 4. Rimpiazzare sezioni non modificabili con traduzioni
41
Appendice B. GNU Free Documentation License (traduzione italiana)
richiede un particolare permesso da parte dei detentori del diritto d’autore, ma si possono includere
traduzioni di una o più sezioni non modificabili in aggiunta alle versioni originali di queste sezioni
immutabili. Si può fornire una traduzione della presente licenza a patto che si includa anche l’originale
versione inglese di questa licenza. In caso di discordanza fra la traduzione e l’originale inglese di questa
licenza la versione originale inglese prevale sempre.
9. TERMINI
Non si può applicare un’altra licenza al documento, copiarlo, modificarlo, o distribuirlo al di fuori dei
termini espressamente previsti da questa licenza. Ogni altro tentativo di applicare un’altra licenza al
documento, copiarlo, modificarlo, o distribuirlo è deprecato e pone fine automaticamente ai diritti
previsti da questa licenza. Comunque, per quanti abbiano ricevuto copie o abbiano diritti coperti da
questa licenza, essi non ne cessano se si rimane perfettamente coerenti con quanto previsto dalla stessa.
Se non ci sono Sezioni non Modificabili, si scriva "senza Sezioni non Modificabili" invece di dire quali
sono non modificabili. Se non c’è Testo Copertina, si scriva "nessun Testo Copertina" invece di "il testo
Copertina è ELENCO"; e allo stesso modo si operi per il Testo di Retro Copertina.
Se il vostro documento contiene esempi non banali di programma in codice sorgente si raccomanda di
realizzare gli esempi contemporaneamente applicandovi anche una licenza di software libero di vostra
42
Appendice B. GNU Free Documentation License (traduzione italiana)
43