doc:it_IT: translation for maintainer-pgp-guide
It translates the maintainer-pgp-guide in Italian. Signed-off-by: Alessia Mantegazza <amantegazza@vaga.pv.it> Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
Alessia Mantegazza
Jonathan Corbet
parent
bba757d857
commit
5ee2345604
|
|
@ -1,13 +1,946 @@
|
|||
.. include:: ../disclaimer-ita.rst
|
||||
|
||||
:Original: :ref:`Documentation/process/maintainer-pgp-guide.rst <pgpguide>`
|
||||
:Translator: Alessia Mantegazza <amantegazza@vaga.pv.it>
|
||||
|
||||
.. _it_pgpguide:
|
||||
|
||||
=========================================
|
||||
La guida a PGP per manutentori del kernel
|
||||
=========================================
|
||||
|
||||
:Author: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
||||
|
||||
Questo documento è destinato agli sviluppatori del kernel Linux, in particolar
|
||||
modo ai manutentori. Contiene degli approfondimenti riguardo informazioni che
|
||||
sono state affrontate in maniera più generale nella sezione
|
||||
"`Protecting Code Integrity`_" pubblicata dalla Linux Foundation.
|
||||
Per approfondire alcuni argomenti trattati in questo documento è consigliato
|
||||
leggere il documento sopraindicato
|
||||
|
||||
.. _`Protecting Code Integrity`: https://github.com/lfit/itpol/blob/master/protecting-code-integrity.md
|
||||
|
||||
Il ruolo di PGP nello sviluppo del kernel Linux
|
||||
===============================================
|
||||
|
||||
PGP aiuta ad assicurare l'integrità del codice prodotto dalla comunità
|
||||
di sviluppo del kernel e, in secondo luogo, stabilisce canali di comunicazione
|
||||
affidabili tra sviluppatori attraverso lo scambio di email firmate con PGP.
|
||||
|
||||
Il codice sorgente del kernel Linux è disponibile principalmente in due
|
||||
formati:
|
||||
|
||||
- repositori distribuiti di sorgenti (git)
|
||||
- rilasci periodici di istantanee (archivi tar)
|
||||
|
||||
Sia i repositori git che gli archivi tar portano le firme PGP degli
|
||||
sviluppatori che hanno creato i rilasci ufficiali del kernel. Queste firme
|
||||
offrono una garanzia crittografica che le versioni scaricabili rese disponibili
|
||||
via kernel.org, o altri portali, siano identiche a quelle che gli sviluppatori
|
||||
hanno sul loro posto di lavoro. A tal scopo:
|
||||
|
||||
- i repositori git forniscono firme PGP per ogni tag
|
||||
- gli archivi tar hanno firme separate per ogni archivio
|
||||
|
||||
.. _it_devs_not_infra:
|
||||
|
||||
Fidatevi degli sviluppatori e non dell'infrastruttura
|
||||
-----------------------------------------------------
|
||||
|
||||
Fin dal 2011, quando i sistemi di kernel.org furono compromessi, il principio
|
||||
generale del progetto Kernel Archives è stato quello di assumere che qualsiasi
|
||||
parte dell'infrastruttura possa essere compromessa in ogni momento. Per questa
|
||||
ragione, gli amministratori hanno intrapreso deliberatemene dei passi per
|
||||
enfatizzare che la fiducia debba risiedere sempre negli sviluppatori e mai nel
|
||||
codice che gestisce l'infrastruttura, indipendentemente da quali che siano le
|
||||
pratiche di sicurezza messe in atto.
|
||||
|
||||
Il principio sopra indicato è la ragione per la quale è necessaria questa
|
||||
guida. Vogliamo essere sicuri che il riporre la fiducia negli sviluppatori
|
||||
non sia fatto semplicemente per incolpare qualcun'altro per future falle di
|
||||
sicurezza. L'obiettivo è quello di fornire una serie di linee guida che gli
|
||||
sviluppatori possano seguire per creare un ambiente di lavoro sicuro e
|
||||
salvaguardare le chiavi PGP usate nello stabilire l'integrità del kernel Linux
|
||||
stesso.
|
||||
|
||||
.. _it_pgp_tools:
|
||||
|
||||
Strumenti PGP
|
||||
=============
|
||||
|
||||
Usare GnuPG v2
|
||||
--------------
|
||||
|
||||
La vostra distribuzione potrebbe avere già installato GnuPG, dovete solo
|
||||
verificare che stia utilizzando la versione 2.x e non la serie 1.4 --
|
||||
molte distribuzioni forniscono entrambe, di base il comando ''gpg''
|
||||
invoca GnuPG v.1. Per controllate usate::
|
||||
|
||||
$ gpg --version | head -n1
|
||||
|
||||
Se visualizzate ``gpg (GnuPG) 1.4.x``, allora state usando GnuPG v.1.
|
||||
Provate il comando ``gpg2`` (se non lo avete, potreste aver bisogno
|
||||
di installare il pacchetto gnupg2)::
|
||||
|
||||
$ gpg2 --version | head -n1
|
||||
|
||||
Se visualizzate ``gpg (GnuPG) 2.x.x``, allora siete pronti a partire.
|
||||
Questa guida assume che abbiate la versione 2.2.(o successiva) di GnuPG.
|
||||
Se state usando la versione 2.0, alcuni dei comandi indicati qui non
|
||||
funzioneranno, in questo caso considerate un aggiornamento all'ultima versione,
|
||||
la 2.2. Versioni di gnupg-2.1.11 e successive dovrebbero essere compatibili
|
||||
per gli obiettivi di questa guida.
|
||||
|
||||
Se avete entrambi i comandi: ``gpg`` e ``gpg2``, assicuratevi di utilizzare
|
||||
sempre la versione V2, e non quella vecchia. Per evitare errori potreste creare
|
||||
un alias::
|
||||
|
||||
$ alias gpg=gpg2
|
||||
|
||||
Potete mettere questa opzione nel vostro ``.bashrc`` in modo da essere sicuri.
|
||||
|
||||
Configurare le opzioni di gpg-agent
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
L'agente GnuPG è uno strumento di aiuto che partirà automaticamente ogni volta
|
||||
che userete il comando ``gpg`` e funzionerà in background con l'obiettivo di
|
||||
individuare la passphrase. Ci sono due opzioni che dovreste conoscere
|
||||
per personalizzare la scadenza della passphrase nella cache:
|
||||
|
||||
- ``default-cache-ttl`` (secondi): Se usate ancora la stessa chiave prima
|
||||
che il time-to-live termini, il conto alla rovescia si resetterà per un
|
||||
altro periodo. Di base è di 600 (10 minuti).
|
||||
|
||||
- ``max-cache-ttl`` (secondi): indipendentemente da quanto sia recente l'ultimo
|
||||
uso della chiave da quando avete inserito la passphrase, se il massimo
|
||||
time-to-live è scaduto, dovrete reinserire nuovamente la passphrase.
|
||||
Di base è di 30 minuti.
|
||||
|
||||
Se ritenete entrambe questi valori di base troppo corti (o troppo lunghi),
|
||||
potete creare il vostro file ``~/.gnupg/gpg-agent.conf`` ed impostare i vostri
|
||||
valori::
|
||||
|
||||
# set to 30 minutes for regular ttl, and 2 hours for max ttl
|
||||
default-cache-ttl 1800
|
||||
max-cache-ttl 7200
|
||||
|
||||
.. note::
|
||||
|
||||
Non è più necessario far partire l'agente gpg manualmente all'inizio della
|
||||
vostra sessione. Dovreste controllare i file rc per rimuovere tutto ciò che
|
||||
riguarda vecchie le versioni di GnuPG, poiché potrebbero non svolgere più
|
||||
bene il loro compito.
|
||||
|
||||
Impostare un *refresh* con cronjob
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Potreste aver bisogno di rinfrescare regolarmente il vostro portachiavi in
|
||||
modo aggiornare le chiavi pubbliche di altre persone, lavoro che è svolto
|
||||
al meglio con un cronjob giornaliero::
|
||||
|
||||
@daily /usr/bin/gpg2 --refresh >/dev/null 2>&1
|
||||
|
||||
Controllate il percorso assoluto del vostro comando ``gpg`` o ``gpg2`` e usate
|
||||
il comando ``gpg2`` se per voi ``gpg`` corrisponde alla versione GnuPG v.1.
|
||||
|
||||
.. _it_master_key:
|
||||
|
||||
Proteggere la vostra chiave PGP primaria
|
||||
========================================
|
||||
Guida a PGP per i manutentori del kernel
|
||||
========================================
|
||||
|
||||
Questa guida parte dal presupposto che abbiate già una chiave PGP che usate
|
||||
per lo sviluppo del kernel Linux. Se non ne avete ancora una, date uno sguardo
|
||||
al documento "`Protecting Code Integrity`_" che abbiamo menzionato prima.
|
||||
|
||||
Dovreste inoltre creare una nuova chiave se quella attuale è inferiore a 2048
|
||||
bit (RSA).
|
||||
|
||||
Chiave principale o sottochiavi
|
||||
-------------------------------
|
||||
|
||||
Le sottochiavi sono chiavi PGP totalmente indipendenti, e sono collegate alla
|
||||
chiave principale attraverso firme certificate. È quindi importante
|
||||
comprendere i seguenti punti:
|
||||
|
||||
1. Non ci sono differenze tecniche tra la chiave principale e la sottochiave.
|
||||
2. In fesa di creazione, assegniamo limitazioni funzionali ad ogni chiave
|
||||
assegnando capacità specifiche.
|
||||
3. Una chiave PGP può avere 4 capacità:
|
||||
|
||||
- **[S]** può essere usata per firmare
|
||||
- **[E]** può essere usata per criptare
|
||||
- **[A]** può essere usata per autenticare
|
||||
- **[C]** può essere usata per certificare altre chiavi
|
||||
|
||||
4. Una singola chiave può avere più capacità
|
||||
5. Una sottochiave è completamente indipendente dalla chiave principale.
|
||||
Un messaggio criptato con la sottochiave non può essere decrittato con
|
||||
quella principale. Se perdete la vostra sottochiave privata, non può
|
||||
essere rigenerata in nessun modo da quella principale.
|
||||
|
||||
La chiave con capacità **[C]** (certify) è identificata come la chiave
|
||||
principale perché è l'unica che può essere usata per indicare la relazione
|
||||
con altre chiavi. Solo la chiave **[C]** può essere usata per:
|
||||
|
||||
- Aggiungere o revocare altre chiavi (sottochiavi) che hanno capacità S/E/A
|
||||
- Aggiungere, modificare o eliminare le identità (unids) associate alla chiave
|
||||
- Aggiungere o modificare la data di termine di sé stessa o di ogni sottochiave
|
||||
- Firmare le chiavi di altre persone a scopo di creare una rete di fiducia
|
||||
|
||||
Di base, alla creazione di nuove chiavi, GnuPG genera quanto segue:
|
||||
|
||||
- Una chiave madre che porta sia la capacità di certificazione che quella
|
||||
di firma (**[SC]**)
|
||||
- Una sottochiave separata con capacità di criptaggio (**[E]**)
|
||||
|
||||
Se avete usato i parametri di base per generare la vostra chiave, quello
|
||||
sarà il risultato. Potete verificarlo utilizzando ``gpg --list-secret-keys``,
|
||||
per esempio::
|
||||
|
||||
sec rsa2048 2018-01-23 [SC] [expires: 2020-01-23]
|
||||
000000000000000000000000AAAABBBBCCCCDDDD
|
||||
uid [ultimate] Alice Dev <adev@kernel.org>
|
||||
ssb rsa2048 2018-01-23 [E] [expires: 2020-01-23]
|
||||
|
||||
Qualsiasi chiave che abbia la capacità **[C]** è la vostra chiave madre,
|
||||
indipendentemente da quali altre capacità potreste averle assegnato.
|
||||
|
||||
La lunga riga sotto la voce ``sec`` è la vostra impronta digitale --
|
||||
negli esempi che seguono, quando vedere ``[fpr]`` ci si riferisce a questa
|
||||
stringa di 40 caratteri.
|
||||
|
||||
Assicuratevi che la vostra passphrase sia forte
|
||||
-----------------------------------------------
|
||||
|
||||
GnuPG utilizza le passphrases per criptare la vostra chiave privata prima
|
||||
di salvarla sul disco. In questo modo, anche se il contenuto della vostra
|
||||
cartella ``.gnupg`` venisse letto o trafugato nella sia interezza, gli
|
||||
attaccanti non potrebbero comunque utilizzare le vostre chiavi private senza
|
||||
aver prima ottenuto la passphrase per decriptarle.
|
||||
|
||||
È assolutamente essenziale che le vostre chiavi private siano protette da
|
||||
una passphrase forte. Per impostarla o cambiarla, usate::
|
||||
|
||||
$ gpg --change-passphrase [fpr]
|
||||
|
||||
Create una sottochiave di firma separata
|
||||
----------------------------------------
|
||||
|
||||
Il nostro obiettivo è di proteggere la chiave primaria spostandola su un
|
||||
dispositivo sconnesso dalla rete, dunque se avete solo una chiave combinata
|
||||
**[SC]** allora dovreste creare una sottochiave di firma separata::
|
||||
|
||||
$ gpg --quick-add-key [fpr] ed25519 sign
|
||||
|
||||
Ricordate di informare il keyserver del vostro cambiamento, cosicché altri
|
||||
possano ricevere la vostra nuova sottochiave::
|
||||
|
||||
$ gpg --send-key [fpr]
|
||||
|
||||
.. note:: Supporto ECC in GnuPG
|
||||
GnuPG 2.1 e successivi supportano pienamente *Elliptic Curve Cryptography*,
|
||||
con la possibilità di combinare sottochiavi ECC con le tradizionali chiavi
|
||||
primarie RSA. Il principale vantaggio della crittografia ECC è che è molto
|
||||
più veloce da calcolare e crea firme più piccole se confrontate byte per
|
||||
byte con le chiavi RSA a più di 2048 bit. A meno che non pensiate di
|
||||
utilizzare un dispositivo smartcard che non supporta le operazioni ECC, vi
|
||||
raccomandiamo ti creare sottochiavi di firma ECC per il vostro lavoro col
|
||||
kernel.
|
||||
|
||||
Se per qualche ragione preferite rimanere con sottochiavi RSA, nel comando
|
||||
precedente, sostituite "ed25519" con "rsa2048".
|
||||
|
||||
Copia di riserva della chiave primaria per gestire il recupero da disastro
|
||||
--------------------------------------------------------------------------
|
||||
|
||||
Maggiori sono le firme di altri sviluppatori che vengono applicate alla vostra,
|
||||
maggiori saranno i motivi per avere una copia di riserva che non sia digitale,
|
||||
al fine di effettuare un recupero da disastro.
|
||||
|
||||
Il modo migliore per creare una copia fisica della vostra chiave privata è
|
||||
l'uso del programma ``paperkey``. Consultate ``man paperkey`` per maggiori
|
||||
dettagli sul formato dell'output ed i suoi punti di forza rispetto ad altre
|
||||
soluzioni. Paperkey dovrebbe essere già pacchettizzato per la maggior parte
|
||||
delle distribuzioni.
|
||||
|
||||
Eseguite il seguente comando per creare una copia fisica di riserva della
|
||||
vostra chiave privata::
|
||||
|
||||
$ gpg --export-secret-key [fpr] | paperkey -o /tmp/key-backup.txt
|
||||
|
||||
Stampate il file (o fate un pipe direttamente verso lpr), poi prendete
|
||||
una penna e scrivete la passphare sul margine del foglio. **Questo è
|
||||
caldamente consigliato** perché la copia cartacea è comunque criptata con
|
||||
la passphrase, e se mai doveste cambiarla non vi ricorderete qual'era al
|
||||
momento della creazione di quella copia -- *garantito*.
|
||||
|
||||
Mettete la copia cartacea e la passphrase scritta a mano in una busta e
|
||||
mettetela in un posto sicuro e ben protetto, preferibilmente fuori casa,
|
||||
magari in una cassetta di sicurezza in banca.
|
||||
|
||||
.. note::
|
||||
|
||||
Probabilmente la vostra stampante non è più quello stupido dispositivo
|
||||
connesso alla porta parallela, ma dato che il suo output è comunque
|
||||
criptato con la passphrase, eseguire la stampa in un sistema "cloud"
|
||||
moderno dovrebbe essere comunque relativamente sicuro. Un'opzione potrebbe
|
||||
essere quella di cambiare la passphrase della vostra chiave primaria
|
||||
subito dopo aver finito con paperkey.
|
||||
|
||||
Copia di riserva di tutta la cartella GnuPG
|
||||
-------------------------------------------
|
||||
|
||||
.. warning::
|
||||
|
||||
TODO ancora da tradurre
|
||||
**!!!Non saltate questo passo!!!**
|
||||
|
||||
Quando avete bisogno di recuperare le vostre chiavi PGP è importante avere
|
||||
una copia di riserva pronta all'uso. Questo sta su un diverso piano di
|
||||
prontezza rispetto al recupero da disastro che abbiamo risolto con
|
||||
``paperkey``. Vi affiderete a queste copie esterne quando dovreste usare la
|
||||
vostra chiave Certify -- ovvero quando fate modifiche alle vostre chiavi o
|
||||
firmate le chiavi di altre persone ad una conferenza o ad un gruppo d'incontro.
|
||||
|
||||
Incominciate con una piccola chiavetta di memoria USB (preferibilmente due)
|
||||
che userete per le copie di riserva. Dovrete criptarle usando LUKS -- fate
|
||||
riferimento alla documentazione della vostra distribuzione per capire come
|
||||
fare.
|
||||
|
||||
Per la passphrase di criptazione, potete usare la stessa della vostra chiave
|
||||
primaria.
|
||||
|
||||
Una volta che il processo di criptazione è finito, reinserite il disco USB ed
|
||||
assicurativi che venga montato correttamente. Copiate interamente la cartella
|
||||
``.gnugp`` nel disco criptato::
|
||||
|
||||
$ cp -a ~/.gnupg /media/disk/foo/gnupg-backup
|
||||
|
||||
Ora dovreste verificare che tutto continui a funzionare::
|
||||
|
||||
$ gpg --homedir=/media/disk/foo/gnupg-backup --list-key [fpr]
|
||||
|
||||
Se non vedete errori, allora dovreste avere fatto tutto con successo.
|
||||
Smontate il disco USB, etichettatelo per bene di modo da evitare di
|
||||
distruggerne il contenuto non appena vi serve una chiavetta USB a caso, ed
|
||||
infine mettetelo in un posto sicuro -- ma non troppo lontano, perché vi servirà
|
||||
di tanto in tanto per modificare le identità, aggiungere o revocare
|
||||
sottochiavi, o firmare le chiavi di altre persone.
|
||||
|
||||
Togliete la chiave primaria dalla vostra home
|
||||
---------------------------------------------
|
||||
|
||||
I file che si trovano nella vostra cartella home non sono poi così ben protetti
|
||||
come potreste pensare. Potrebbero essere letti o trafugati in diversi modi:
|
||||
|
||||
- accidentalmente quando fate una rapida copia della cartella home per
|
||||
configurare una nuova postazione
|
||||
- da un amministratore di sistema negligente o malintenzionato
|
||||
- attraverso copie di riserva insicure
|
||||
- attraverso malware installato in alcune applicazioni (browser, lettori PDF,
|
||||
eccetera)
|
||||
- attraverso coercizione quando attraversate confini internazionali
|
||||
|
||||
Proteggere la vostra chiave con una buona passphare aiuta notevolmente a
|
||||
ridurre i rischi elencati qui sopra, ma le passphrase possono essere scoperte
|
||||
attraverso i keylogger, il shoulder-surfing, o altri modi. Per questi motivi,
|
||||
nella configurazione si raccomanda di rimuove la chiave primaria dalla vostra
|
||||
cartella home e la si archivia su un dispositivo disconnesso.
|
||||
|
||||
.. warning::
|
||||
|
||||
Per favore, fate riferimento alla sezione precedente e assicuratevi
|
||||
di aver fatto una copia di riserva totale della cartella GnuPG. Quello
|
||||
che stiamo per fare renderà la vostra chiave inutile se non avete delle
|
||||
copie di riserva utilizzabili!
|
||||
|
||||
Per prima cosa, identificate il keygrip della vostra chiave primaria::
|
||||
|
||||
$ gpg --with-keygrip --list-key [fpr]
|
||||
|
||||
L'output assomiglierà a questo::
|
||||
|
||||
pub rsa2048 2018-01-24 [SC] [expires: 2020-01-24]
|
||||
000000000000000000000000AAAABBBBCCCCDDDD
|
||||
Keygrip = 1111000000000000000000000000000000000000
|
||||
uid [ultimate] Alice Dev <adev@kernel.org>
|
||||
sub rsa2048 2018-01-24 [E] [expires: 2020-01-24]
|
||||
Keygrip = 2222000000000000000000000000000000000000
|
||||
sub ed25519 2018-01-24 [S]
|
||||
Keygrip = 3333000000000000000000000000000000000000
|
||||
|
||||
Trovate la voce keygrid che si trova sotto alla riga ``pub`` (appena sotto
|
||||
all'impronta digitale della chiave primaria). Questo corrisponderà direttamente
|
||||
ad un file nella cartella ``~/.gnupg``::
|
||||
|
||||
$ cd ~/.gnupg/private-keys-v1.d
|
||||
$ ls
|
||||
1111000000000000000000000000000000000000.key
|
||||
2222000000000000000000000000000000000000.key
|
||||
3333000000000000000000000000000000000000.key
|
||||
|
||||
Quello che dovrete fare è rimuovere il file .key che corrisponde al keygrip
|
||||
della chiave primaria::
|
||||
|
||||
$ cd ~/.gnupg/private-keys-v1.d
|
||||
$ rm 1111000000000000000000000000000000000000.key
|
||||
|
||||
Ora, se eseguite il comando ``--list-secret-keys``, vedrete che la chiave
|
||||
primaria non compare più (il simbolo ``#`` indica che non è disponibile)::
|
||||
|
||||
$ gpg --list-secret-keys
|
||||
sec# rsa2048 2018-01-24 [SC] [expires: 2020-01-24]
|
||||
000000000000000000000000AAAABBBBCCCCDDDD
|
||||
uid [ultimate] Alice Dev <adev@kernel.org>
|
||||
ssb rsa2048 2018-01-24 [E] [expires: 2020-01-24]
|
||||
ssb ed25519 2018-01-24 [S]
|
||||
|
||||
Dovreste rimuovere anche i file ``secring.gpg`` che si trovano nella cartella
|
||||
``~/.gnupg``, in quanto rimasugli delle versioni precedenti di GnuPG.
|
||||
|
||||
Se non avete la cartella "private-keys-v1.d"
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Se non avete la cartella ``~/.gnupg/private-keys-v1.d``, allora le vostre
|
||||
chiavi segrete sono ancora salvate nel vecchio file ``secring.gpg`` usato
|
||||
da GnuPG v1. Effettuare una qualsiasi modifica alla vostra chiave, come
|
||||
cambiare la passphare o aggiungere una sottochiave, dovrebbe convertire
|
||||
automaticamente il vecchio formato ``secring.gpg``nel nuovo
|
||||
``private-keys-v1.d``.
|
||||
|
||||
Una volta che l'avete fatto, assicuratevi di rimuovere il file ``secring.gpg``,
|
||||
che continua a contenere la vostra chiave privata.
|
||||
|
||||
.. _it_smartcards:
|
||||
|
||||
Spostare le sottochiavi in un apposito dispositivo criptato
|
||||
===========================================================
|
||||
|
||||
Nonostante la chiave primaria sia ora al riparo da occhi e mani indiscrete,
|
||||
le sottochiavi si trovano ancora nella vostra cartella home. Chiunque riesca
|
||||
a mettere le sue mani su quelle chiavi riuscirà a decriptare le vostre
|
||||
comunicazioni o a falsificare le vostre firme (se conoscono la passphrase).
|
||||
Inoltre, ogni volta che viene fatta un'operazione con GnuPG, le chiavi vengono
|
||||
caricate nella memoria di sistema e potrebbero essere rubate con l'uso di
|
||||
malware sofisticati (pensate a Meltdown e a Spectre).
|
||||
|
||||
Il miglior modo per proteggere le proprie chiave è di spostarle su un
|
||||
dispositivo specializzato in grado di effettuare operazioni smartcard.
|
||||
|
||||
I benefici di una smartcard
|
||||
---------------------------
|
||||
|
||||
Una smartcard contiene un chip crittografico che è capace di immagazzinare
|
||||
le chiavi private ed effettuare operazioni crittografiche direttamente sulla
|
||||
carta stessa. Dato che la chiave non lascia mai la smartcard, il sistema
|
||||
operativo usato sul computer non sarà in grado di accedere alle chiavi.
|
||||
Questo è molto diverso dai dischi USB criptati che abbiamo usato allo scopo di
|
||||
avere una copia di riserva sicura -- quando il dispositivo USB è connesso e
|
||||
montato, il sistema operativo potrà accedere al contenuto delle chiavi private.
|
||||
|
||||
L'uso di un disco USB criptato non può sostituire le funzioni di un dispositivo
|
||||
capace di operazioni di tipo smartcard.
|
||||
|
||||
Dispositivi smartcard disponibili
|
||||
---------------------------------
|
||||
|
||||
A meno che tutti i vostri computer dispongano di lettori smartcard, il modo
|
||||
più semplice è equipaggiarsi di un dispositivo USB specializzato che
|
||||
implementi le funzionalità delle smartcard. Sul mercato ci sono diverse
|
||||
soluzioni disponibili:
|
||||
|
||||
- `Nitrokey Start`_: è Open hardware e Free Software, è basata sul progetto
|
||||
`GnuK`_ della FSIJ. Ha il supporto per chiavi ECC, ma meno funzionalità di
|
||||
sicurezza (come la resistenza alla manomissione o alcuni attacchi ad un
|
||||
canale laterale).
|
||||
- `Nitrokey Pro`_: è simile alla Nitrokey Start, ma è più resistente alla
|
||||
manomissione e offre più funzionalità di sicurezza, ma l'ECC.
|
||||
- `Yubikey 4`_: l'hardware e il software sono proprietari, ma è più economica
|
||||
della Nitrokey Pro ed è venduta anche con porta USB-C il che è utile con i
|
||||
computer portatili più recenti. In aggiunta, offre altre funzionalità di
|
||||
sicurezza come FIDO, U2F, ma non l'ECC
|
||||
|
||||
`Su LWN c'è una buona recensione`_ dei modelli elencati qui sopra e altri.
|
||||
Se volete usare chiavi ECC, la vostra migliore scelta sul mercato è la
|
||||
Nitrokey Start.
|
||||
|
||||
.. _`Nitrokey Start`: https://shop.nitrokey.com/shop/product/nitrokey-start-6
|
||||
.. _`Nitrokey Pro`: https://shop.nitrokey.com/shop/product/nitrokey-pro-3
|
||||
.. _`Yubikey 4`: https://www.yubico.com/product/yubikey-4-series/
|
||||
.. _Gnuk: http://www.fsij.org/doc-gnuk/
|
||||
.. _`Su LWN c'è una buona recensione`: https://lwn.net/Articles/736231/
|
||||
|
||||
Configurare il vostro dispositivo smartcard
|
||||
-------------------------------------------
|
||||
|
||||
Il vostro dispositivo smartcard dovrebbe iniziare a funzionare non appena
|
||||
lo collegate ad un qualsiasi computer Linux moderno. Potete verificarlo
|
||||
eseguendo::
|
||||
|
||||
$ gpg --card-status
|
||||
|
||||
Se vedete tutti i dettagli della smartcard, allora ci siamo. Sfortunatamente,
|
||||
affrontare tutti i possibili motivi per cui le cose potrebbero non funzionare
|
||||
non è lo scopo di questa guida. Se avete problemi nel far funzionare la carta
|
||||
con GnuPG, cercate aiuto attraverso i soliti canali di supporto.
|
||||
|
||||
Per configurare la vostra smartcard, dato che non c'è una via facile dalla
|
||||
riga di comando, dovrete usate il menu di GnuPG::
|
||||
|
||||
$ gpg --card-edit
|
||||
[...omitted...]
|
||||
gpg/card> admin
|
||||
Admin commands are allowed
|
||||
gpg/card> passwd
|
||||
|
||||
Dovreste impostare il PIN dell'utente (1), quello dell'amministratore (3) e il
|
||||
codice di reset (4). Assicuratevi di annotare e salvare questi codici in un
|
||||
posto sicuro -- specialmente il PIN dell'amministratore e il codice di reset
|
||||
(che vi permetterà di azzerare completamente la smartcard). Il PIN
|
||||
dell'amministratore viene usato così raramente che è inevitabile dimenticarselo
|
||||
se non lo si annota.
|
||||
|
||||
Tornando al nostro menu, potete impostare anche altri valori (come il nome,
|
||||
il sesso, informazioni d'accesso, eccetera), ma non sono necessari e aggiunge
|
||||
altre informazioni sulla carta che potrebbero trapelare in caso di smarrimento.
|
||||
|
||||
.. note::
|
||||
|
||||
A dispetto del nome "PIN", né il PIN utente né quello dell'amministratore
|
||||
devono essere esclusivamente numerici.
|
||||
|
||||
Spostare le sottochiavi sulla smartcard
|
||||
---------------------------------------
|
||||
|
||||
Uscite dal menu (usando "q") e salverete tutte le modifiche. Poi, spostiamo
|
||||
tutte le sottochiavi sulla smartcard. Per la maggior parte delle operazioni
|
||||
vi serviranno sia la passphrase della chiave PGP che il PIN
|
||||
dell'amministratore::
|
||||
|
||||
$ gpg --edit-key [fpr]
|
||||
|
||||
Secret subkeys are available.
|
||||
|
||||
pub rsa2048/AAAABBBBCCCCDDDD
|
||||
created: 2018-01-23 expires: 2020-01-23 usage: SC
|
||||
trust: ultimate validity: ultimate
|
||||
ssb rsa2048/1111222233334444
|
||||
created: 2018-01-23 expires: never usage: E
|
||||
ssb ed25519/5555666677778888
|
||||
created: 2017-12-07 expires: never usage: S
|
||||
[ultimate] (1). Alice Dev <adev@kernel.org>
|
||||
|
||||
gpg>
|
||||
|
||||
Usando ``--edit-key`` si tornerà alla modalità menu e noterete che
|
||||
la lista delle chiavi è leggermente diversa. Da questo momento in poi,
|
||||
tutti i comandi saranno eseguiti nella modalità menu, come indicato
|
||||
da ``gpg>``.
|
||||
|
||||
Per prima cosa, selezioniamo la chiave che verrà messa sulla carta --
|
||||
potete farlo digitando ``key 1`` (è la prima della lista, la sottochiave
|
||||
**[E]**)::
|
||||
|
||||
gpg> key 1
|
||||
|
||||
Nel'output dovreste vedere ``ssb*`` associato alla chiave **[E]**. Il simbolo
|
||||
``*`` indica che la chiave è stata "selezionata". Funziona come un
|
||||
interruttore, ovvero se scrivete nuovamente ``key 1``, il simbolo ``*`` sparirà
|
||||
e la chiave non sarà più selezionata.
|
||||
|
||||
Ora, spostiamo la chiave sulla smartcard::
|
||||
|
||||
gpg> keytocard
|
||||
Please select where to store the key:
|
||||
(2) Encryption key
|
||||
Your selection? 2
|
||||
|
||||
Dato che è la nostra chiave **[E]**, ha senso metterla nella sezione criptata.
|
||||
Quando confermerete la selezione, vi verrà chiesta la passphrase della vostra
|
||||
chiave PGP, e poi il PIN dell'amministratore. Se il comando ritorna senza
|
||||
errori, allora la vostra chiave è stata spostata con successo.
|
||||
|
||||
**Importante**: digitate nuovamente ``key 1`` per deselezionare la prima chiave
|
||||
e selezionate la seconda chiave **[S]** con ``key 2``::
|
||||
|
||||
gpg> key 1
|
||||
gpg> key 2
|
||||
gpg> keytocard
|
||||
Please select where to store the key:
|
||||
(1) Signature key
|
||||
(3) Authentication key
|
||||
Your selection? 1
|
||||
|
||||
Potete usare la chiave **[S]** sia per firmare che per autenticare, ma vogliamo
|
||||
che sia nella sezione di firma, quindi scegliete (1). Ancora una volta, se il
|
||||
comando ritorna senza errori, allora l'operazione è avvenuta con successo::
|
||||
|
||||
gpg> q
|
||||
Save changes? (y/N) y
|
||||
|
||||
Salvando le modifiche cancellerete dalla vostra cartella home tutte le chiavi
|
||||
che avete spostato sulla carta (ma questo non è un problema, perché abbiamo
|
||||
fatto delle copie di sicurezza nel caso in cui dovessimo configurare una
|
||||
nuova smartcard).
|
||||
|
||||
Verificare che le chiavi siano state spostate
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Ora, se doveste usare l'opzione ``--list-secret-keys``, vedrete una
|
||||
sottile differenza nell'output::
|
||||
|
||||
$ gpg --list-secret-keys
|
||||
sec# rsa2048 2018-01-24 [SC] [expires: 2020-01-24]
|
||||
000000000000000000000000AAAABBBBCCCCDDDD
|
||||
uid [ultimate] Alice Dev <adev@kernel.org>
|
||||
ssb> rsa2048 2018-01-24 [E] [expires: 2020-01-24]
|
||||
ssb> ed25519 2018-01-24 [S]
|
||||
|
||||
Il simbolo ``>`` in ``ssb>`` indica che la sottochiave è disponibile solo
|
||||
nella smartcard. Se tornate nella vostra cartella delle chiavi segrete e
|
||||
guardate al suo contenuto, noterete che i file ``.key`` sono stati sostituiti
|
||||
con degli stub::
|
||||
|
||||
$ cd ~/.gnupg/private-keys-v1.d
|
||||
$ strings *.key | grep 'private-key'
|
||||
|
||||
Per indicare che i file sono solo degli stub e che in realtà il contenuto è
|
||||
sulla smartcard, l'output dovrebbe mostrarvi ``shadowed-private-key``.
|
||||
|
||||
Verificare che la smartcard funzioni
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Per verificare che la smartcard funzioni come dovuto, potete creare
|
||||
una firma::
|
||||
|
||||
$ echo "Hello world" | gpg --clearsign > /tmp/test.asc
|
||||
$ gpg --verify /tmp/test.asc
|
||||
|
||||
Col primo comando dovrebbe chiedervi il PIN della smartcard, e poi dovrebbe
|
||||
mostrare "Good signature" dopo l'esecuzione di ``gpg --verify``.
|
||||
|
||||
Complimenti, siete riusciti a rendere estremamente difficile il furto della
|
||||
vostra identità digitale di sviluppatore.
|
||||
|
||||
Altre operazioni possibili con GnuPG
|
||||
------------------------------------
|
||||
|
||||
Segue un breve accenno ad alcune delle operazioni più comuni che dovrete
|
||||
fare con le vostre chiavi PGP.
|
||||
|
||||
Montare il disco con la chiave primaria
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Vi servirà la vostra chiave principale per tutte le operazioni che seguiranno,
|
||||
per cui per prima cosa dovrete accedere ai vostri backup e dire a GnuPG di
|
||||
usarli::
|
||||
|
||||
$ export GNUPGHOME=/media/disk/foo/gnupg-backup
|
||||
$ gpg --list-secret-keys
|
||||
|
||||
Dovete assicurarvi di vedere ``sec`` e non ``sec#`` nell'output del programma
|
||||
(il simbolo ``#`` significa che la chiave non è disponibile e che state ancora
|
||||
utilizzando la vostra solita cartella di lavoro).
|
||||
|
||||
Estendere la data di scadenza di una chiave
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
La chiave principale ha una data di scadenza di 2 anni dal momento della sua
|
||||
creazione. Questo per motivi di sicurezza e per rendere obsolete le chiavi
|
||||
che, eventualmente, dovessero sparire dai keyserver.
|
||||
|
||||
Per estendere di un anno, dalla data odierna, la scadenza di una vostra chiave,
|
||||
eseguite::
|
||||
|
||||
$ gpg --quick-set-expire [fpr] 1y
|
||||
|
||||
Se per voi è più facile da memorizzare, potete anche utilizzare una data
|
||||
specifica (per esempio, il vostro compleanno o capodanno)::
|
||||
|
||||
$ gpg --quick-set-expire [fpr] 2020-07-01
|
||||
|
||||
Ricordatevi di inviare l'aggiornamento ai keyserver::
|
||||
|
||||
$ gpg --send-key [fpr]
|
||||
|
||||
Aggiornare la vostra cartella di lavoro dopo ogni modifica
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Dopo aver fatto delle modifiche alle vostre chiavi usando uno spazio a parte,
|
||||
dovreste importarle nella vostra cartella di lavoro abituale::
|
||||
|
||||
$ gpg --export | gpg --homedir ~/.gnupg --import
|
||||
$ unset GNUPGHOME
|
||||
|
||||
|
||||
Usare PGP con Git
|
||||
=================
|
||||
|
||||
Una delle caratteristiche fondanti di Git è la sua natura decentralizzata --
|
||||
una volta che il repositorio è stato clonato sul vostro sistema, avete la
|
||||
storia completa del progetto, inclusi i suoi tag, i commit ed i rami. Tuttavia,
|
||||
con i centinaia di repositori clonati che ci sono in giro, come si fa a
|
||||
verificare che la loro copia di linux.git non è stata manomessa da qualcuno?
|
||||
|
||||
Oppure, cosa succede se viene scoperta una backdoor nel codice e la riga
|
||||
"Autore" dice che sei stato tu, mentre tu sei abbastanza sicuro di
|
||||
`non averci niente a che fare`_?
|
||||
|
||||
Per risolvere entrambi i problemi, Git ha introdotto l'integrazione con PGP.
|
||||
I tag firmati dimostrano che il repositorio è integro assicurando che il suo
|
||||
contenuto è lo stesso che si trova sulle macchine degli sviluppatori che hanno
|
||||
creato il tag; mentre i commit firmati rendono praticamente impossibile
|
||||
ad un malintenzionato di impersonarvi senza avere accesso alle vostre chiavi
|
||||
PGP.
|
||||
|
||||
.. _`non averci niente a che fare`: https://github.com/jayphelps/git-blame-someone-else
|
||||
|
||||
Configurare git per usare la vostra chiave PGP
|
||||
----------------------------------------------
|
||||
|
||||
Se avete solo una chiave segreta nel vostro portachiavi, allora non avete nulla
|
||||
da fare in più dato che sarà la vostra chiave di base. Tuttavia, se doveste
|
||||
avere più chiavi segrete, potete dire a git quale dovrebbe usare (``[fpg]``
|
||||
è la vostra impronta digitale)::
|
||||
|
||||
$ git config --global user.signingKey [fpr]
|
||||
|
||||
**IMPORTANTE**: se avete una comando dedicato per ``gpg2``, allora dovreste
|
||||
dire a git di usare sempre quello piuttosto che il vecchio comando ``gpg``::
|
||||
|
||||
$ git config --global gpg.program gpg2
|
||||
|
||||
Come firmare i tag
|
||||
------------------
|
||||
|
||||
Per creare un tag firmato, passate l'opzione ``-s`` al comando tag::
|
||||
|
||||
$ git tag -s [tagname]
|
||||
|
||||
La nostra raccomandazione è quella di firmare sempre i tag git, perché
|
||||
questo permette agli altri sviluppatori di verificare che il repositorio
|
||||
git dal quale stanno prendendo il codice non è stato alterato intenzionalmente.
|
||||
|
||||
Come verificare i tag firmati
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Per verificare un tag firmato, potete usare il comando ``verify-tag``::
|
||||
|
||||
$ git verify-tag [tagname]
|
||||
|
||||
Se state prendendo un tag da un fork del repositorio del progetto, git
|
||||
dovrebbe verificare automaticamente la firma di quello che state prendendo
|
||||
e vi mostrerà il risultato durante l'operazione di merge::
|
||||
|
||||
$ git pull [url] tags/sometag
|
||||
|
||||
Il merge conterrà qualcosa di simile::
|
||||
|
||||
Merge tag 'sometag' of [url]
|
||||
|
||||
[Tag message]
|
||||
|
||||
# gpg: Signature made [...]
|
||||
# gpg: Good signature from [...]
|
||||
|
||||
Se state verificando il tag di qualcun altro, allora dovrete importare
|
||||
la loro chiave PGP. Fate riferimento alla sezione ":ref:`it_verify_identities`"
|
||||
che troverete più avanti.
|
||||
|
||||
Configurare git per firmare sempre i tag con annotazione
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Se state creando un tag con annotazione è molto probabile che vogliate
|
||||
firmarlo. Per imporre a git di firmare sempre un tag con annotazione,
|
||||
dovete impostare la seguente opzione globale::
|
||||
|
||||
$ git config --global tag.forceSignAnnotated true
|
||||
|
||||
Come usare commit firmati
|
||||
-------------------------
|
||||
|
||||
Creare dei commit firmati è facile, ma è molto più difficile utilizzarli
|
||||
nello sviluppo del kernel linux per via del fatto che ci si affida alle
|
||||
liste di discussione e questo modo di procedere non mantiene le firme PGP
|
||||
nei commit. In aggiunta, quando si usa *rebase* nel proprio repositorio
|
||||
locale per allinearsi al kernel anche le proprie firme PGP verranno scartate.
|
||||
Per questo motivo, la maggior parte degli sviluppatori del kernel non si
|
||||
preoccupano troppo di firmare i propri commit ed ignoreranno quelli firmati
|
||||
che si trovano in altri repositori usati per il proprio lavoro.
|
||||
|
||||
Tuttavia, se avete il vostro repositorio di lavoro disponibile al pubblico
|
||||
su un qualche servizio di hosting git (kernel.org, infradead.org, ozlabs.org,
|
||||
o altri), allora la raccomandazione è di firmare tutti i vostri commit
|
||||
anche se gli sviluppatori non ne beneficeranno direttamente.
|
||||
|
||||
Vi raccomandiamo di farlo per i seguenti motivi:
|
||||
|
||||
1. Se dovesse mai esserci la necessità di fare delle analisi forensi o
|
||||
tracciare la provenienza di un codice, anche sorgenti mantenuti
|
||||
esternamente che hanno firme PGP sui commit avranno un certo valore a
|
||||
questo scopo.
|
||||
2. Se dovesse mai capitarvi di clonare il vostro repositorio locale (per
|
||||
esempio dopo un danneggiamento del disco), la firma vi permetterà di
|
||||
verificare l'integrità del repositorio prima di riprendere il lavoro.
|
||||
3. Se qualcuno volesse usare *cherry-pick* sui vostri commit, allora la firma
|
||||
permetterà di verificare l'integrità dei commit prima di applicarli.
|
||||
|
||||
Creare commit firmati
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Per creare un commit firmato, dovete solamente aggiungere l'opzione ``-S``
|
||||
al comando ``git commit`` (si usa la lettera maiuscola per evitare
|
||||
conflitti con un'altra opzione)::
|
||||
|
||||
$ git commit -S
|
||||
|
||||
Configurare git per firmare sempre i commit
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Potete dire a git di firmare sempre i commit::
|
||||
|
||||
git config --global commit.gpgSign true
|
||||
|
||||
.. note::
|
||||
|
||||
Assicuratevi di aver configurato ``gpg-agent`` prima di abilitare
|
||||
questa opzione.
|
||||
|
||||
.. _it_verify_identities:
|
||||
|
||||
Come verificare l'identità degli sviluppatori del kernel
|
||||
========================================================
|
||||
|
||||
Firmare i tag e i commit è facile, ma come si fa a verificare che la chiave
|
||||
usata per firmare qualcosa appartenga davvero allo sviluppatore e non ad un
|
||||
impostore?
|
||||
|
||||
Configurare l'auto-key-retrieval usando WKD e DANE
|
||||
--------------------------------------------------
|
||||
|
||||
Se non siete ancora in possesso di una vasta collezione di chiavi pubbliche
|
||||
di altri sviluppatori, allora potreste iniziare il vostro portachiavi
|
||||
affidandovi ai servizi di auto-scoperta e auto-recupero. GnuPG può affidarsi
|
||||
ad altre tecnologie di delega della fiducia, come DNSSEC e TLS, per sostenervi
|
||||
nel caso in cui iniziare una propria rete di fiducia da zero sia troppo
|
||||
scoraggiante.
|
||||
|
||||
Aggiungete il seguente testo al vostro file ``~/.gnupg/gpg.conf``::
|
||||
|
||||
auto-key-locate wkd,dane,local
|
||||
auto-key-retrieve
|
||||
|
||||
La *DNS-Based Authentication of Named Entities* ("DANE") è un metodo
|
||||
per la pubblicazione di chiavi pubbliche su DNS e per renderle sicure usando
|
||||
zone firmate con DNSSEC. Il *Web Key Directory* ("WKD") è un metodo
|
||||
alternativo che usa https a scopo di ricerca. Quando si usano DANE o WKD
|
||||
per la ricerca di chiavi pubbliche, GnuPG validerà i certificati DNSSEC o TLS
|
||||
prima di aggiungere al vostro portachiavi locale le eventuali chiavi trovate.
|
||||
|
||||
Kernel.org pubblica la WKD per tutti gli sviluppatori che hanno un account
|
||||
kernel.org. Una volta che avete applicato le modifiche al file ``gpg.conf``,
|
||||
potrete auto-recuperare le chiavi di Linus Torvalds e Greg Kroah-Hartman
|
||||
(se non le avete già)::
|
||||
|
||||
$ gpg --locate-keys torvalds@kernel.org gregkh@kernel.org
|
||||
|
||||
Se avete un account kernel.org, al fine di rendere più utile l'uso di WKD
|
||||
da parte di altri sviluppatori del kernel, dovreste `aggiungere alla vostra
|
||||
chiave lo UID di kernel.org`_.
|
||||
|
||||
.. _`aggiungere alla vostra chiave lo UID di kernel.org`: https://korg.wiki.kernel.org/userdoc/mail#adding_a_kernelorg_uid_to_your_pgp_key
|
||||
|
||||
Web of Trust (WOT) o Trust on First Use (TOFU)
|
||||
----------------------------------------------
|
||||
|
||||
PGP incorpora un meccanismo di delega della fiducia conosciuto come
|
||||
"Web of Trust". Di base, questo è un tentativo di sostituire la necessità
|
||||
di un'autorità certificativa centralizzata tipica del mondo HTTPS/TLS.
|
||||
Invece di avere svariati produttori software che decidono chi dovrebbero
|
||||
essere le entità di certificazione di cui dovreste fidarvi, PGP lascia
|
||||
la responsabilità ad ogni singolo utente.
|
||||
|
||||
Sfortunatamente, solo poche persone capiscono come funziona la rete di fiducia.
|
||||
Nonostante sia un importante aspetto della specifica OpenPGP, recentemente
|
||||
le versioni di GnuPG (2.2 e successive) hanno implementato un meccanisco
|
||||
alternativo chiamato "Trust on First Use" (TOFU). Potete pensare a TOFU come
|
||||
"ad un approccio all fidicia simile ad SSH". In SSH, la prima volta che vi
|
||||
connettete ad un sistema remoto, l'impronta digitale della chiave viene
|
||||
registrata e ricordata. Se la chiave dovesse cambiare in futuro, il programma
|
||||
SSH vi avviserà e si rifiuterà di connettersi, obbligandovi a prendere una
|
||||
decisione circa la fiducia che riponete nella nuova chiave. In modo simile,
|
||||
la prima volta che importate la chiave PGP di qualcuno, si assume sia valida.
|
||||
Se ad un certo punto GnuPG trova un'altra chiave con la stessa identità,
|
||||
entrambe, la vecchia e la nuova, verranno segnate come invalide e dovrete
|
||||
verificare manualmente quale tenere.
|
||||
|
||||
Vi raccomandiamo di usare il meccanisco TOFU+PGP (che è la nuova configurazione
|
||||
di base di GnuPG v2). Per farlo, aggiungete (o modificate) l'impostazione
|
||||
``trust-model`` in ``~/.gnupg/gpg.conf``::
|
||||
|
||||
trust-model tofu+pgp
|
||||
|
||||
Come usare i keyserver in sicurezza
|
||||
-----------------------------------
|
||||
Se ottenete l'errore "No public key" quando cercate di validate il tag di
|
||||
qualcuno, allora dovreste cercare quella chiave usando un keyserver. È
|
||||
importante tenere bene a mente che non c'è alcuna garanzia che la chiave
|
||||
che avete recuperato da un keyserver PGP appartenga davvero alla persona
|
||||
reale -- è progettato così. Dovreste usare il Web of Trust per assicurarvi
|
||||
che la chiave sia valida.
|
||||
|
||||
Come mantenere il Web of Trust va oltre gli scopi di questo documento,
|
||||
semplicemente perché farlo come si deve richiede sia sforzi che perseveranza
|
||||
che tendono ad andare oltre al livello di interesse della maggior parte degli
|
||||
esseri umani. Qui di seguito alcuni rapidi suggerimenti per aiutarvi a ridurre
|
||||
il rischio di importare chiavi maligne.
|
||||
|
||||
Primo, diciamo che avete provato ad eseguire ``git verify-tag`` ma restituisce
|
||||
un errore dicendo che la chiave non è stata trovata::
|
||||
|
||||
$ git verify-tag sunxi-fixes-for-4.15-2
|
||||
gpg: Signature made Sun 07 Jan 2018 10:51:55 PM EST
|
||||
gpg: using RSA key DA73759BF8619E484E5A3B47389A54219C0F2430
|
||||
gpg: issuer "wens@...org"
|
||||
gpg: Can't check signature: No public key
|
||||
|
||||
Cerchiamo nel keyserver per maggiori informazioni sull'impronta digitale
|
||||
della chiave (l'impronta digitale, probabilmente, appartiene ad una
|
||||
sottochiave, dunque non possiamo usarla direttamente senza trovare prima
|
||||
l'ID della chiave primaria associata ad essa)::
|
||||
|
||||
$ gpg --search DA73759BF8619E484E5A3B47389A54219C0F2430
|
||||
gpg: data source: hkp://keys.gnupg.net
|
||||
(1) Chen-Yu Tsai <wens@...org>
|
||||
4096 bit RSA key C94035C21B4F2AEB, created: 2017-03-14, expires: 2019-03-15
|
||||
Keys 1-1 of 1 for "DA73759BF8619E484E5A3B47389A54219C0F2430". Enter number(s), N)ext, or Q)uit > q
|
||||
|
||||
Localizzate l'ID della chiave primaria, nel nostro esempio
|
||||
``C94035C21B4F2AEB``. Ora visualizzate le chiavi di Linus Torvalds
|
||||
che avete nel vostro portachiavi::
|
||||
|
||||
$ gpg --list-key torvalds@kernel.org
|
||||
pub rsa2048 2011-09-20 [SC]
|
||||
ABAF11C65A2970B130ABE3C479BE3E4300411886
|
||||
uid [ unknown] Linus Torvalds <torvalds@kernel.org>
|
||||
sub rsa2048 2011-09-20 [E]
|
||||
|
||||
Poi, aprite il `PGP pathfinder`_. Nel campo "From", incollate l'impronta
|
||||
digitale della chiave di Linus Torvalds che si vede nell'output qui sopra.
|
||||
Nel campo "to", incollate il key-id della chiave sconosciuta che avete
|
||||
trovato con ``gpg --search``, e poi verificare il risultato:
|
||||
|
||||
- `Finding paths to Linus`_
|
||||
|
||||
Se trovate un paio di percorsi affidabili è un buon segno circa la validità
|
||||
della chiave. Ora, potete aggiungerla al vostro portachiavi dal keyserver::
|
||||
|
||||
$ gpg --recv-key C94035C21B4F2AEB
|
||||
|
||||
Questa procedura non è perfetta, e ovviamente state riponendo la vostra
|
||||
fiducia nell'amministratore del servizio *PGP Pathfinder* sperando che non
|
||||
sia malintenzionato (infatti, questo va contro :ref:`it_devs_not_infra`).
|
||||
Tuttavia, se mantenete con cura la vostra rete di fiducia sarà un deciso
|
||||
miglioramento rispetto alla cieca fiducia nei keyserver.
|
||||
|
||||
.. _`PGP pathfinder`: https://pgp.cs.uu.nl/
|
||||
.. _`Finding paths to Linus`: https://pgp.cs.uu.nl/paths/79BE3E4300411886/to/C94035C21B4F2AEB.html
|
||||
|
|
|
|||
Loading…
Reference in New Issue