GnuPG

Versioni Compatibili Tutte le versioni supportate di Debian

Questa guida è basata sui seguenti articoli presenti all'interno del numero 4 dell'e-zine di Debianizzati.org : PGP: configurazione e utilizzo in Debian

Introduzione

GnuPG (Gnu Privacy Guard o, in breve, GPG) fa parte del progetto GNU e si pone come una alternativa completamente open a PGP. Inoltre è totalmente aderente allo standard OpenPGP per cui è compatibile con tutti i programmi che ne fanno uso.
GnuPG consente di cifrare attraverso ciò che viene definita "crittografia asimmetrica", ossia una cifratura dei messaggi utilizzando una coppia di chiavi: la chiave privata e la chiave pubblica.
Da qui anche il nome di "crittografia a chiavi asimmetriche" e "crittografia a chiavi simmetriche".

Il sistema a chiave simmetrica prevede che l'algoritmo di decodifica utilizzi la stessa chiave privata per cifrare e decifrare i messaggi da proteggere.
Il sistema a chiave asimmetrica, invece, prevede l'utilizzo di una coppia di chiavi: pubblica e privata. Con la chiave pubblica del destinatario si cifra un messaggio. Il destinatario lo decifrerà con la propria chiave privata.
Questi concetti verranno ripresi ed ampliati nel corso della guida.

Installazione

Apriamo il nostro terminale e installiamo GnuPG. È sufficiente un:

# apt-get install gnupg

Creazione delle chiavi

Procediamo adesso con la creazione della chiavi.
Sempre da terminale, ad installazione completata ma come utente comune, digitiamo:

$ gpg --gen-key

per accedere ad un menù di scelta attraverso cui gpg ci chiederà alcune informazioni per generare le chiavi.

Scelta dell'algoritmo

La prima richiesta da parte di gpg riguarda l'algoritmo (o gli algoritmi) da utilizzare. Davanti a noi si presenteranno quattro opzioni:

Per favore scegli che tipo di chiave vuoi:

(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (firma solo)
(4) RSA (firma solo)

Notare che con le opzioni (1) e (2) in realtà verranno create due coppie di chiavi:

master keypair

la coppia di chiavi principale che verrà utilizzata per creare firme digitali

subordinate keypair

la coppia di chiavi subordinata (spesso la troverete con il nome di subkey) utilizzata per cifrare i dati.

GnuPG deciderà automaticamente quale coppia di chiavi usare a seconda dell'operazione da svolgere per cui per, comodità, in genere si fa sempre riferimento ad un'unica coppia di chiavi.

Le opzioni sono:

RSA and RSA (default)

verrà creata una chiave principale per le firme digitali e una chiave secondaria per la cifratura; in entrambi i casi verrà utilizzato l'algoritmo RSA. Questa è la scelta di default.

DSA and Elgamal

verrà creata una chiave principale DSA per le firme digitali e una chiave Elgamal secondaria per la cifratura.

RSA (firma solo)

verrà creata solo la chiave principale RSA per le firme digitali.

DSA (firma solo)

verrà creata solo la chiave principale DSA per le firme digitali.

Le opzioni (3) e (4) sono utili se:

• Si vuole soltanto creare firme digitali e non si è interessati a cifrare i dati.
• Si vogliono creare chiavi di diversa lunghezza.

Creare chiave principale e subordinata

Scegliamo l'opzione (1) per iniziare a creare chiavi RSA.

Per favore scegli che tipo di chiave vuoi:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (firma solo)
(4) RSA (firma solo)
Cosa scegli? 1

Lunghezza della chiave

Adesso ci verrà richiesta la lunghezza in bit della chiave da creare:

RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)

il valore di default (2048 bit) può andare più che bene; ovviamente maggiore è la lunghezza, maggiore sarà la sicurezza ma i tempi di cifratura e decifrazione saranno più lunghi.
Sono ammessi tutti i valori tra 1024 e 4096, premendo [Invio] si accetta il consiglio di gpg per creare chiavi di 2048 bit.

Se non avete problemi di velocità computazionale o se, soprattutto, la sicurezza è un fattore assolutamente essenziale e preponderante, la scelta deve ricadere sulla massima lunghezza consentita: 4096 bit.
La lunghezza, una volta stabilita, non potrà più essere modificata.

Durata della chiave

Dopo aver inserito la lunghezza della chiave RSA, procediamo premendo "invio". Nella schermata successiva, ci verrà chiesto per quanti giorni la chiave deve valere: le opzioni sono molte e noi sceglieremo la numero 0, ovvero nessuna scadenza:

Per favore specifica per quanto tempo la chiave sarà valida.

0 = la chiave non scadrà
<n> = la chiave scadrà dopo n giorni
<n>w = la chiave scadrà dopo n settimane
<n>m = la chiave scadrà dopo n mesi
<n>y = la chiave scadrà dopo n anni
Chiave valida per? (0) 0

Il sistema ci chiederà quindi di confermare la scelta effettuata:

Key does not expire at all
Is this correct? (y/N) y

Premendo "invio", giungeremo alla compilazione dei dati che precede la creazione della chiave pubblica e di quella privata.

You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:

"Heinrich Heine (Der Dichter) !heinrichh@duesseldorf.de?"

Dovremo a questo punto inserire il nostro Nome e Cognome, un indirizzo email valido e un commento (facoltativo):

Nome e Cognome:
Indirizzo di Email:
Commento:

Una volta compilati i campi e data la conferma, ci verrà mostrato il riepilogo delle informazioni inserite con la possibilità di modificarle, di cancellarle o di accettarle:

Hai selezionato questo User Id:
Modifica (N)ome, (C)ommento, (E)mail oppure (O)kay/(Q)uit?

Ci verrà chiesto di inserire una passphrase che servirà per la protezione della chiave.
Questo è un passaggio importante: bisogna cercare di scegliere una buona passphrase e di non dimenticarla.
Confermata la passphrase, comparirà una richiesta di esecuzione di altre operazioni per la generazione dei numeri primi (la creazione di RSA si basa proprio su questi numeri per aumentare l'entropia), per cui, quando leggeremo queste righe:

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

riduciamo il terminale e cominciamo a fare qualsiasi altra cosa: aprire documenti, digitare lettere a caso, giocare e ascoltare musica. L'importante è far lavorare il processore: nel caso ciò non accadesse, sullo schermo comparirà un avviso:

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

proseguiamo a lavorare, e quando i byte saranno stati accumulati, il computer automaticamente genererà le chiavi.
A lavoro completato si otterrà un messaggio simile a questo:

gpg: /home/pincopallino/.gnupg/trustdb.gpg: creato il trustdb
gpg: key 20ACD5A1 marked as ultimately trusted
chiavi pubbliche e segrete create e firmate.

86 Tips & Tricks
gpg: controllo il trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
pub 1024R/20ACD5A1 2010-02-11

Key fingerprint = 10 gruppi da 4 cifre che comporranno la "key finger print"
uid Nome Cognome () !email?
sub 1024R/7DB807FC 2010-02-11

Le chiavi sono state create con successo!

Nota importante La scelta della passphrase è un passaggio fondamentale nel processo di creazione della coppia di chiavi. Chiunque dovesse riuscire ad impadronirsi della chiave privata dovrebbe riuscire ad oltrepassare la cifratura della chiave privata stessa. Una buona passphrase è quella facile da ricordare ma che altri difficilmente possono indovinare o violare tramite attacco brute force. Ecco perché essa dovrebbe essere lunga e costituita da un insieme di caratteri alfabetici (maiuscoli e minuscoli), caratteri speciali e numeri.

Crittografia simmetrica

Questo sistema crittografico prevede l'utilizzo di una sola chiave per la cifratura e la decifrazione.
La sua affidabilità è basata esclusivamente sulla robustezza dell'algoritmo di cifratura (di solito DES - Data Encryption Standard -).
Facciamo un esempio pratico cifrando un messaggio presente nella nostra $HOME contenuto nel file "file-segreto.txt".
Prima di tutto leggiamo le chiavi presenti nel nostro keyring identificando i dati relativi a quella creata in precedenza:

$ gpg --list-keys
/home/glider/.gnupg/pubring.gpg
-------------------------------
pub 1024D/3231A5D0 2008-07-26
uid Pinco Pallino (Chiave crittografica di Pinco Pallino) <pinco.pallino@gmail.com>
sub 2048g/3B74F97C 2008-07-26
...
[cut]
...

Procediamo quindi a cifrare il messaggio:

$ gpg -r pinco.pallino@gmail.com --symmetric --encrypt file-segreto.txt

verrà richiesto l'inserimento e la conferma di una passphrase da utilizzare al momento della decifrazione del messaggio e sarà generato il file "file-segreto.txt.gpg", ossia il file cifrato.
Per decifrarlo:

$ gpg -o file-decifrato.txt --decrypt file-segreto.txt.gpg

e dopo l'inserimento della passphrase scelta in precedenza si otterrà il file "file-decifrato.txt".
La debolezza di questo approccio risiede nella necessità di condivisione della chiave di cifratura.
Per questo motivo, oggi, è preferibile affidarsi alla crittografia asimmetrica che garantisce una sicurezza maggiore.

Crittografia asimmetrica

Immaginiamo di disporre di un lucchetto elettronico e di due chiavi che lo aprono: una "pubblica" e una "privata".
Metteremo a disposizione di tutti il lucchetto e la chiave pubblica, in modo tale che ogni persona che vorrà inviarci qualcosa possa chiuderla in un contenitore qualsiasi che sigillerà con il nostro lucchetto elettronico.
Una volta chiuso il tutto (ovvero, dopo aver cifrato il contenuto con PGP), il contenitore ci potrà essere inviato sicuri che nessuno, durante il tragitto, sia in condizione di aprirlo e leggerne il contenuto.
A prima vista, un messaggio cifrato è illeggibile. Anche possedendo la chiave pubblica è impossibile decifrarlo.
È la nostra chiave privata che ci permetterà di riportare in chiaro il messaggio ricevuto.
Possediamo già una coppia di chiavi, una pubblica da distribuire e una privata da tenere, è il caso di inserirle all'interno di file di testo.
La procedura è molto semplice:

$ gpg --export -a pinco.pallino@gmail.com ? chiavepubblica.txt

così facendo si esporta la chiave pubblica, contenuta nel keyring ed appartenente all'utente identificato da quella particolare email, in un file chiamato chiavepubblica.txt.
Procederemo in modo simile all'esportazione della chiave privata:

$ gpg --export-secret-key -a pinco.pallino@gmail.com ? chiaveprivata.txt

e la chiave verrà esportata in un file chiamato chiaveprivata.txt.
Se proviamo ad aprire il file chiavepubblica.txt ci si presenterà davanti un file di questo genere:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.10 (GNU/Linux)

mI0ES3PwoAEEAM38UqWKnbthn1RAIj0EeIBbMOFoJ/UKgL0IyQxVz6JlVcFmWXr4
WzFMp025A0MyeWPj+vwGw42TBqJnS1jwu3cCff1OxsMYuX/afSWYM2tD7ey1nIXt
bLsJyr5Zy2YSOsM80KG77gBlLWJxX6YCjTG076plVI+PeyU2HuyuPdCFABEBAAG0
NUFuZHJlYSBQb3NzZW1hdG8gKHByb3ZhKSA8YW5kcmVhLnBvc3NlbWF0b0BnbWFp
bC5jb20+iLgEEwECACIFAktz8KACGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheA
AAoJELE9UXEgrNWhjnsEALJc+6TAVd6P/S7fFsnWHpPnMX0r1VYvtp8uMmr2wZNa
BLJNY4MsgWAJDMwJbakzdL2DC8ThU9ydUTcBpw2OWQW/i8CAyUkS5GjJ1iQ40tLt
WfPTbAcCIbkJuep7XkFOMMsV/nJKbFMySKUCii3KFtj7nllxLQRbyhSsRr9LJ9Mo
.........................
.........................
-----END PGP PUBLIC KEY BLOCK-----

Questa è la chiave pubblica che potremo consegnare a chi vogliamo e che permetterà di comunicare in modo sicuro con noi.
Facciamo un esempio pratico.
Ipotizziamo che qualcuno voglia inviarci un file cifrato.
Questa persona dovrà aggiungere la nostra chiave pubblica al proprio keyring:

$ gpg --import chiavepubblica.txt

Se l'importazione è andata a buon fine, dando:

$ gpg --list-key

vedrà nella lista anche la nuova chiave appena aggiunta.
Per la cifratura proseguirà ripetendo i passaggi su indicati inserendo nel campo UID la nostra email.
Completata la cifratura, ci invierà il messaggio cifrato che noi potremo decifrare inserendo la nostra passphrase, visto che quel file è stato cifrato con la nostra chiave pubblica!

Repository e GPG

Per garantire che un determinato repository sia fidato, in Debian si utilizza una chiave di cifratura GPG.
L'autenticazione è di forma univoca, ovvero una chiave GPG può autenticare un solo repository. Per i repository ufficiali, l'acquisizione della chiave di cifratura è automatica, infatti non andiamo mai ad aggiungere una chiave GPG al primo avvio della nostra Debian, a meno che non usiamo già dal primo avvio repository non ufficiali. Ma se volessimo usare un repository non ufficiale che richiede l'autenticazione ed essa non viene fatta in automatico? Dobbiamo importare le chiavi GPG per questi repository non ufficiali. Prendiamo l'esempio di deb-multimedia

## DEB MULTIMEDIA
deb http://www.deb-multimedia.org jessie main

apriamo con il nostro editor di testo il file /etc/apt/sources.list e aggiungiamo questo repository. Salviamo e chiudiamo e cominciamo con i comandi.

# apt-get update

alla fine dell'update troveremo però un WARNING di questo tipo:

W: Errore GPG: http://www.deb-multimedia.org jessie InRelease: Le seguenti firme non sono state verificate perché la chiave pubblica non è disponibile: NO_PUBKEY 07DC563D1F41B907

analizziamo bene questo avvertimento: il sistema ci comunica che non è stato possibile verificare la firma del repository perché manca della chiave pubblica di riferimento.
La chiave che il sistema cerca è 07DC563D1F41B907. Sono a questo punto possibili due strade:

• Si installa il pacchetto "deb-multimedia-keyring"
• Si importa la chiave pubblica da un keyserver

Seguiamo il secondo metodo per completezza, visto che il primo metodo è abbastanza banale.
Preleviamo dal keyserver predisposto la chiave pubblica e utilizziamo apt-key per aggiungerla al portachiavi utilizzato da apt per verificare la firma dei repository:

# apt-key adv --keyserver subkeys.pgp.net --recv-keys 07DC563D1F41B907

Fatto questo, daremo nuovamente l'update con:

# apt-get update

e se non otterremo altri Warning vorrà dire che avremo importato la chiave in modo corretto.
Saremo parimenti certi che, da quel momento in poi, i pacchetti scaricati proverranno da una fonte sicura.
Perchè?
Il meccanismo di funzionamento della "crittografia asimmetrica" dovrebbe ormai essere chiaro: la chiave pubblica (quella conosciuta da tutti) serve a cifrare un file, per leggere il quale sarà necessaria la chiave privata (che deve essere tenuta segreta).
È però possibile usare la chiave privata per "'firmare"' un file e non solo per decifrarlo: in questo caso, chiunque sia in possesso di chiave pubblica potrà verificare che quel file sia stato firmato da quella chiave privata.
Ogni repository Debian contiene un file Release che viene aggiornato ogni volta che un pacchetto dell'archivio cambia e che contiene anche i "checksum" di altri file sempre contenuti in quel repository. Tra questi ci sono i file "Packages.gz".
Questo uno stralcio del file Release presente nei repository di Debian Lenny:

Origin: Debian
Label: Debian
Suite: stable
Version: 5.0.4
Codename: lenny
Date: Fri, 29 Jan 2010 23:18:16 UTC
Architectures: alpha amd64 arm armel hppa i386 ia64 mips mipsel powerpc s390 sparc
Components: main contrib non-free
Description: Debian 5.0.4 Released 29 January 2010
MD5Sum:

5a5774342de8498b6c39666a287277cb 13513135 Contents-powerpc.gz
31e526616dffa65cbd000aba82049fb8 13210302 Contents-armel.gz
a663bc33ed6e79c0256053cd30226987 13157248 Contents-alpha.gz
d8b6b3e5097edcda8d280211fa5df4ca 13824603 Contents-i386.gz
...
[cut]
...

dda6fb2fc2e6ed6d41a6a0786c05e5bd 24354793 main/binary-i386/Packages
56df8601bb6c9fc91e899e88cbd6fe3d 6724599 main/binary-i386/Packages.gz !------
9e32cd68e56b8ae0120b2e278e5a30d3 5196154 main/binary-i386/Packages.bz2
6f8ee24cb11bb35bfff84442b5f23c02 95 main/binary-i386/Release
...
[cut]
...

Ogni file "Packages.gz", parimenti, contiene un checksum per ogni pacchetto in esso listato.
Eccone uno stralcio:

...
[cut]
...
Package: 3dchess
Priority: optional
Section: games
Installed-Size: 100
Maintainer: Debian Games Team !pkg-games-devel@lists.alioth.debian.org?
Architecture: i386
Version: 0.8.1-15
Depends: libc6 (?= 2.7-1), libx11-6, libxext6, libxmu6, libxpm4, libxt6, "

xaw3dg (?= 1.5+E-1)
Filename: pool/main/3/3dchess/3dchess.0.8.1-15.i386.deb
Size: 34526
MD5sum: 4605788bdc35ee2e7ff419162f86c126 !------------
SHA1: 27415ead5f8bf401d73bd9f0fb9ea24cd727e54e
SHA256: e1231555d343e141fbd803998537032e4af78695d523a0e8f65b2f6f4d38226f
Description: 3D chess for X11

3 dimensional Chess game for X11R6. There are three boards, stacked
vertically; 96 pieces of which most are the traditional chess pieces with
just a couple of additions; 26 possible directions in which to move. The
AI isn't wonderful, but provides a challenging enough game to all but the
most highly skilled players.
Tag: game::board, game::board:chess, implemented-in::c, interface::x11, "

role::program, uitoolkit::xlib, use::gameplaying, x11::application
...
[cut]
...

Mediante il confronto del checksum relativo al file "Packages.gz" contenuto nel Release file e del checksum del file "Packages.gz" contenuto nei repository, apt capisce se la copia scaricata di "Package.gz" file è corretta.
Quando poi scarica un singolo pacchetto, apt esegue il check di questo con quanto contenuto nel file "Packages.gz".
La firma crittografica del file Release è costituita da un file chiamato "Release.gpg" che viene fornito insieme al file Release.
Ecco il contenuto di http://ftp.it.debian.org/debian/dists/lenny/Release.gpg:

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAABAgAGBQJLY2zLAAoJEJqjjc1VvjAr6E0QAJMm3HWcrMd3GPUxQ/tThtNz
PsIUH5Bkd5LwHGXnRntz/pF1eeQPZ9VvwTNc0q+AP5ZP21/q3kiTFBbaqTkqXsc0
QOiF2mKMI+tv4iJaLqMI/IBEAXqwyIdDGXzuyCG50RxajKmARb4Npab2OqSz/Dy3
IMROR9wy8tzPnCtyVnkOZ7I1Vz0AF5JQYBCCDscQJu4O7i6t5itqkgF0vA/FvXJ2
GHOQPSAVOAMhd1vudVjn9bu5mP6cAT6wQoJKa/uNs5pRlotC2qN4unZKleZ2NHvU
9E7pVleKb1ND07dFPQZjDdT7Ir7B4J2Ma7yHXn8nFdPRrOHb0/fXBC5js0XgenHH
ZASRQeZnjVh8PRAZDU47bhF9DIsaxnbds0DMMLFhMDQM2vGjQlTcWRoEPm1QMLv+
ttL7aD4rrq/S413cKodqaR9TnuXjydNoja8Od/cgtH9VvMKVtBbPdhjn749Fx5Hw
b3fnwmzTbgguzsleRyF9/fJIBSuVc9TQH42GmCa7OsCB7wRHlOEdyj/4FtFfP37R
0gYTVQeeV5l9wP/cun3boWyhGSg2cXwhPKFU+I7cDW2TobQ3I/eUrodeyr/ikrPe
iLqGsUXBIWmlAC7NGUBrITQw6rouc82qnDSKR+RLPBuXZeEVRy95d+LI+CvPa0sr
TiHtlcssVR+1v/d1G9Qk
=/CSh
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEABECAAYFAktjbk0ACgkQTScNBvQlhOYVJgCgg1ry+a9GkDe5EDGy8M5ReE64
/TIAn1WqrgX49oOr6RVLXil2roYhCaX/
=003L
-----END PGP SIGNATURE-----

Se apt non riesce a scaricare Release.gpg o se la firma non è verificata, avvisa che il "Packages.gz" al quale il file Release fa riferimento (e ovviamente tutti i file in esso listati) provengono da una fonte non verificata.
Il meccanismo di sicurezza si basa sulla verifica dell'esistenza e della validità di Release.gpg, validità accertata eseguendo il controllo di quella firma.
Per eseguire tale controllo, apt deve conoscere la chiave pubblica della persona che l'ha firmato (come detto la firma avviene per mezzo della propria chiave privata).
Tali chiavi pubbliche sono contenute nel keyring /etc/apt/trusted.gpg:

# apt-key list
/etc/apt/trusted.gpg
--------------------
pub 1024D/6070D3A1 2006-11-20 [expired: 2009-07-01]
uid Debian Archive Automatic Signing Key (4.0/etch) "

!ftpmaster@debian.org?

pub 1024D/ADB11277 2006-09-17
uid Etch Stable Release Key !debian-release@lists.debian.org?

pub 1024D/BBE55AB3 2007-03-31 [expired: 2010-03-30]
uid Debian-Volatile Archive Automatic Signing Key (4.0/etch)

pub 1024D/F42584E6 2008-04-06 [expires: 2012-05-15]
uid Lenny Stable Release Key !debian-release@lists.debian.org?
...
[cut]
...

È questa, per concludere, la ratio del funzionamento di GPG: una "catena di fiducia".
Le chiavi, firmate e gestite come appena esposto, sono gli unici veri garanti dell'affidabilità del repository. Buon GPG a tutti!

---

Guida scritta da: Greyfox	Debianized 40%
Estesa da:
Verificata da: Pmate
Verificare ed estendere la guida | Cos'è una guida Debianized