1.. include:: ../disclaimer-ita.rst
2
3:Original: :ref:`Documentation/process/maintainer-pgp-guide.rst <pgpguide>`
4:Translator: Alessia Mantegazza <amantegazza@vaga.pv.it>
5
6.. _it_pgpguide:
7
8=========================================
9La guida a PGP per manutentori del kernel
10=========================================
11
12:Author: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
13
14Questo documento è destinato agli sviluppatori del kernel Linux, in particolar
15modo ai manutentori. Contiene degli approfondimenti riguardo informazioni che
16sono state affrontate in maniera più generale nella sezione
17"`Protecting Code Integrity`_" pubblicata dalla Linux Foundation.
18Per approfondire alcuni argomenti trattati in questo documento è consigliato
19leggere il documento sopraindicato
20
21.. _`Protecting Code Integrity`: https://github.com/lfit/itpol/blob/master/protecting-code-integrity.md
22
23Il ruolo di PGP nello sviluppo del kernel Linux
24===============================================
25
26PGP aiuta ad assicurare l'integrità del codice prodotto dalla comunità
27di sviluppo del kernel e, in secondo luogo, stabilisce canali di comunicazione
28affidabili tra sviluppatori attraverso lo scambio di email firmate con PGP.
29
30Il codice sorgente del kernel Linux è disponibile principalmente in due
31formati:
32
33- repositori distribuiti di sorgenti (git)
34- rilasci periodici di istantanee (archivi tar)
35
36Sia i repositori git che gli archivi tar portano le firme PGP degli
37sviluppatori che hanno creato i rilasci ufficiali del kernel. Queste firme
38offrono una garanzia crittografica che le versioni scaricabili rese disponibili
39via kernel.org, o altri portali, siano identiche a quelle che gli sviluppatori
40hanno sul loro posto di lavoro. A tal scopo:
41
42- i repositori git forniscono firme PGP per ogni tag
43- gli archivi tar hanno firme separate per ogni archivio
44
45.. _it_devs_not_infra:
46
47Fidatevi degli sviluppatori e non dell'infrastruttura
48-----------------------------------------------------
49
50Fin dal 2011, quando i sistemi di kernel.org furono compromessi, il principio
51generale del progetto Kernel Archives è stato quello di assumere che qualsiasi
52parte dell'infrastruttura possa essere compromessa in ogni momento. Per questa
53ragione, gli amministratori hanno intrapreso deliberatemene dei passi per
54enfatizzare che la fiducia debba risiedere sempre negli sviluppatori e mai nel
55codice che gestisce l'infrastruttura, indipendentemente da quali che siano le
56pratiche di sicurezza messe in atto.
57
58Il principio sopra indicato è la ragione per la quale è necessaria questa
59guida. Vogliamo essere sicuri che il riporre la fiducia negli sviluppatori
60non sia fatto semplicemente per incolpare qualcun'altro per future falle di
61sicurezza. L'obiettivo è quello di fornire una serie di linee guida che gli
62sviluppatori possano seguire per creare un ambiente di lavoro sicuro e
63salvaguardare le chiavi PGP usate nello stabilire l'integrità del kernel Linux
64stesso.
65
66.. _it_pgp_tools:
67
68Strumenti PGP
69=============
70
71Usare GnuPG v2
72--------------
73
74La vostra distribuzione potrebbe avere già installato GnuPG, dovete solo
75verificare che stia utilizzando la versione 2.x e non la serie 1.4 --
76molte distribuzioni forniscono entrambe, di base il comando ''gpg''
77invoca GnuPG v.1. Per controllate usate::
78
79    $ gpg --version | head -n1
80
81Se visualizzate ``gpg (GnuPG) 1.4.x``, allora state usando GnuPG v.1.
82Provate il comando ``gpg2`` (se non lo avete, potreste aver bisogno
83di installare il pacchetto gnupg2)::
84
85    $ gpg2 --version | head -n1
86
87Se visualizzate  ``gpg (GnuPG) 2.x.x``, allora siete pronti a partire.
88Questa guida assume che abbiate la versione 2.2.(o successiva) di GnuPG.
89Se state usando la versione 2.0, alcuni dei comandi indicati qui non
90funzioneranno, in questo caso considerate un aggiornamento all'ultima versione,
91la 2.2. Versioni di gnupg-2.1.11 e successive dovrebbero essere compatibili
92per gli obiettivi di questa guida.
93
94Se avete entrambi i comandi: ``gpg`` e ``gpg2``, assicuratevi di utilizzare
95sempre la versione V2, e non quella vecchia. Per evitare errori potreste creare
96un alias::
97
98    $ alias gpg=gpg2
99
100Potete mettere questa opzione nel vostro  ``.bashrc`` in modo da essere sicuri.
101
102Configurare le opzioni di gpg-agent
103~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
104
105L'agente GnuPG è uno strumento di aiuto che partirà automaticamente ogni volta
106che userete il comando ``gpg`` e funzionerà in background con l'obiettivo di
107individuare la passphrase. Ci sono due opzioni che dovreste conoscere
108per personalizzare la scadenza della passphrase nella cache:
109
110- ``default-cache-ttl`` (secondi): Se usate ancora la stessa chiave prima
111  che il time-to-live termini, il conto alla rovescia si resetterà per un
112  altro periodo. Di base è di 600 (10 minuti).
113
114- ``max-cache-ttl`` (secondi): indipendentemente da quanto sia recente l'ultimo
115  uso della chiave da quando avete inserito la passphrase, se il massimo
116  time-to-live è scaduto, dovrete reinserire nuovamente la passphrase.
117  Di base è di 30 minuti.
118
119Se ritenete entrambe questi valori di base troppo corti (o troppo lunghi),
120potete creare il vostro file ``~/.gnupg/gpg-agent.conf`` ed impostare i vostri
121valori::
122
123    # set to 30 minutes for regular ttl, and 2 hours for max ttl
124    default-cache-ttl 1800
125    max-cache-ttl 7200
126
127.. note::
128
129    Non è più necessario far partire l'agente gpg manualmente all'inizio della
130    vostra sessione. Dovreste controllare i file rc per rimuovere tutto ciò che
131    riguarda vecchie le versioni di GnuPG, poiché potrebbero non svolgere più
132    bene il loro compito.
133
134Impostare un *refresh* con cronjob
135~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
136
137Potreste aver bisogno di rinfrescare regolarmente il vostro portachiavi in
138modo aggiornare le chiavi pubbliche di altre persone, lavoro che è svolto
139al meglio con un cronjob giornaliero::
140
141    @daily /usr/bin/gpg2 --refresh >/dev/null 2>&1
142
143Controllate il percorso assoluto del vostro comando ``gpg`` o ``gpg2`` e usate
144il comando ``gpg2`` se per voi ``gpg`` corrisponde alla versione GnuPG v.1.
145
146.. _it_master_key:
147
148Proteggere la vostra chiave PGP primaria
149========================================
150
151Questa guida parte dal presupposto che abbiate già una chiave PGP che usate
152per lo sviluppo del kernel Linux. Se non ne avete ancora una, date uno sguardo
153al documento "`Protecting Code Integrity`_" che abbiamo menzionato prima.
154
155Dovreste inoltre creare una nuova chiave se quella attuale è inferiore a 2048
156bit (RSA).
157
158Chiave principale o sottochiavi
159-------------------------------
160
161Le sottochiavi sono chiavi PGP totalmente indipendenti, e sono collegate alla
162chiave principale attraverso firme certificate. È quindi importante
163comprendere i seguenti punti:
164
1651. Non ci sono differenze tecniche tra la chiave principale e la sottochiave.
1662. In fesa di creazione, assegniamo limitazioni funzionali ad ogni chiave
167   assegnando capacità specifiche.
1683. Una chiave PGP può avere 4 capacità:
169
170   - **[S]** può essere usata per firmare
171   - **[E]** può essere usata per criptare
172   - **[A]** può essere usata per autenticare
173   - **[C]** può essere usata per certificare altre chiavi
174
1754. Una singola chiave può avere più capacità
1765. Una sottochiave è completamente indipendente dalla chiave principale.
177   Un messaggio criptato con la sottochiave non può essere decrittato con
178   quella principale. Se perdete la vostra sottochiave privata, non può
179   essere rigenerata in nessun modo da quella principale.
180
181La chiave con capacità **[C]** (certify) è identificata come la chiave
182principale perché è l'unica che può essere usata per indicare la relazione
183con altre chiavi. Solo la chiave **[C]** può essere usata per:
184
185- Aggiungere o revocare altre chiavi (sottochiavi) che hanno capacità S/E/A
186- Aggiungere, modificare o eliminare le identità (unids) associate alla chiave
187- Aggiungere o modificare la data di termine di sé stessa o di ogni sottochiave
188- Firmare le chiavi di altre persone a scopo di creare una rete di fiducia
189
190Di base, alla creazione di nuove chiavi, GnuPG genera quanto segue:
191
192- Una chiave madre che porta sia la capacità di certificazione che quella
193  di firma (**[SC]**)
194- Una sottochiave separata con capacità di criptaggio (**[E]**)
195
196Se avete usato i parametri di base per generare la vostra chiave, quello
197sarà il risultato. Potete verificarlo utilizzando ``gpg --list-secret-keys``,
198per esempio::
199
200    sec   rsa2048 2018-01-23 [SC] [expires: 2020-01-23]
201          000000000000000000000000AAAABBBBCCCCDDDD
202    uid           [ultimate] Alice Dev <adev@kernel.org>
203    ssb   rsa2048 2018-01-23 [E] [expires: 2020-01-23]
204
205Qualsiasi chiave che abbia la capacità **[C]** è la vostra chiave madre,
206indipendentemente da quali altre capacità potreste averle assegnato.
207
208La lunga riga sotto la voce ``sec`` è la vostra impronta digitale --
209negli esempi che seguono, quando vedere ``[fpr]`` ci si riferisce a questa
210stringa di 40 caratteri.
211
212Assicuratevi che la vostra passphrase sia forte
213-----------------------------------------------
214
215GnuPG utilizza le passphrases per criptare la vostra chiave privata prima
216di salvarla sul disco. In questo modo, anche se il contenuto della vostra
217cartella ``.gnupg`` venisse letto o trafugato nella sia interezza, gli
218attaccanti non potrebbero comunque utilizzare le vostre chiavi private senza
219aver prima ottenuto la passphrase per decriptarle.
220
221È assolutamente essenziale che le vostre chiavi private siano protette da
222una passphrase forte. Per impostarla o cambiarla, usate::
223
224    $ gpg --change-passphrase [fpr]
225
226Create una sottochiave di firma separata
227----------------------------------------
228
229Il nostro obiettivo è di proteggere la chiave primaria spostandola su un
230dispositivo sconnesso dalla rete, dunque se avete solo una chiave combinata
231**[SC]** allora dovreste creare una sottochiave di firma separata::
232
233    $ gpg --quick-add-key [fpr] ed25519 sign
234
235Ricordate di informare il keyserver del vostro cambiamento, cosicché altri
236possano ricevere la vostra nuova sottochiave::
237
238    $ gpg --send-key [fpr]
239
240.. note:: Supporto ECC in GnuPG
241    GnuPG 2.1 e successivi supportano pienamente *Elliptic Curve Cryptography*,
242    con la possibilità di combinare sottochiavi ECC con le tradizionali chiavi
243    primarie RSA. Il principale vantaggio della crittografia ECC è che è molto
244    più veloce da calcolare e crea firme più piccole se confrontate byte per
245    byte con le chiavi RSA a più di 2048 bit. A meno che non pensiate di
246    utilizzare un dispositivo smartcard che non supporta le operazioni ECC, vi
247    raccomandiamo ti creare sottochiavi di firma ECC per il vostro lavoro col
248    kernel.
249
250    Se per qualche ragione preferite rimanere con sottochiavi RSA, nel comando
251    precedente, sostituite "ed25519" con "rsa2048". In aggiunta, se avete
252    intenzione di usare un dispositivo hardware che non supporta le chiavi
253    ED25519 ECC, come la Nitrokey Pro o la Yubikey, allora dovreste usare
254    "nistp256" al posto di "ed25519".
255
256Copia di riserva della chiave primaria per gestire il recupero da disastro
257--------------------------------------------------------------------------
258
259Maggiori sono le firme di altri sviluppatori che vengono applicate alla vostra,
260maggiori saranno i motivi per avere una copia di riserva che non sia digitale,
261al fine di effettuare un recupero da disastro.
262
263Il modo migliore per creare una copia fisica della vostra chiave privata è
264l'uso del programma ``paperkey``. Consultate ``man paperkey`` per maggiori
265dettagli sul formato dell'output ed i suoi punti di forza rispetto ad altre
266soluzioni. Paperkey dovrebbe essere già pacchettizzato per la maggior parte
267delle distribuzioni.
268
269Eseguite il seguente comando per creare una copia fisica di riserva della
270vostra chiave privata::
271
272    $ gpg --export-secret-key [fpr] | paperkey -o /tmp/key-backup.txt
273
274Stampate il file (o fate un pipe direttamente verso lpr), poi prendete
275una penna e scrivete la passphare sul margine del foglio.  **Questo è
276caldamente consigliato** perché la copia cartacea è comunque criptata con
277la passphrase, e se mai doveste cambiarla non vi ricorderete qual'era al
278momento della creazione di quella copia -- *garantito*.
279
280Mettete la copia cartacea e la passphrase scritta a mano in una busta e
281mettetela in un posto sicuro e ben protetto, preferibilmente fuori casa,
282magari in una cassetta di sicurezza in banca.
283
284.. note::
285
286    Probabilmente la vostra stampante non è più quello stupido dispositivo
287    connesso alla porta parallela, ma dato che il suo output è comunque
288    criptato con la passphrase, eseguire la stampa in un sistema "cloud"
289    moderno dovrebbe essere comunque relativamente sicuro. Un'opzione potrebbe
290    essere quella di cambiare la passphrase della vostra chiave primaria
291    subito dopo aver finito con paperkey.
292
293Copia di riserva di tutta la cartella GnuPG
294-------------------------------------------
295
296.. warning::
297
298    **!!!Non saltate questo passo!!!**
299
300Quando avete bisogno di recuperare le vostre chiavi PGP è importante avere
301una copia di riserva pronta all'uso. Questo sta su un diverso piano di
302prontezza rispetto al recupero da disastro che abbiamo risolto con
303``paperkey``. Vi affiderete a queste copie esterne quando dovreste usare la
304vostra chiave Certify -- ovvero quando fate modifiche alle vostre chiavi o
305firmate le chiavi di altre persone ad una conferenza o ad un gruppo d'incontro.
306
307Incominciate con una piccola chiavetta di memoria USB (preferibilmente due)
308che userete per le copie di riserva. Dovrete criptarle usando LUKS -- fate
309riferimento alla documentazione della vostra distribuzione per capire come
310fare.
311
312Per la passphrase di criptazione, potete usare la stessa della vostra chiave
313primaria.
314
315Una volta che il processo di criptazione è finito, reinserite il disco USB ed
316assicurativi che venga montato correttamente. Copiate interamente la cartella
317``.gnugp`` nel disco criptato::
318
319    $ cp -a ~/.gnupg /media/disk/foo/gnupg-backup
320
321Ora dovreste verificare che tutto continui a funzionare::
322
323    $ gpg --homedir=/media/disk/foo/gnupg-backup --list-key [fpr]
324
325Se non vedete errori, allora dovreste avere fatto tutto con successo.
326Smontate il disco USB, etichettatelo per bene di modo da evitare di
327distruggerne il contenuto non appena vi serve una chiavetta USB a caso, ed
328infine mettetelo in un posto sicuro -- ma non troppo lontano, perché vi servirà
329di tanto in tanto per modificare le identità, aggiungere o revocare
330sottochiavi, o firmare le chiavi di altre persone.
331
332Togliete la chiave primaria dalla vostra home
333---------------------------------------------
334
335I file che si trovano nella vostra cartella home non sono poi così ben protetti
336come potreste pensare. Potrebbero essere letti o trafugati in diversi modi:
337
338- accidentalmente quando fate una rapida copia della cartella home per
339  configurare una nuova postazione
340- da un amministratore di sistema negligente o malintenzionato
341- attraverso copie di riserva insicure
342- attraverso malware installato in alcune applicazioni (browser, lettori PDF,
343  eccetera)
344- attraverso coercizione quando attraversate confini internazionali
345
346Proteggere la vostra chiave con una buona passphare aiuta notevolmente a
347ridurre i rischi elencati qui sopra, ma le passphrase possono essere scoperte
348attraverso i keylogger, il shoulder-surfing, o altri modi. Per questi motivi,
349nella configurazione si raccomanda di rimuove la chiave primaria dalla vostra
350cartella home e la si archivia su un dispositivo disconnesso.
351
352.. warning::
353
354    Per favore, fate riferimento alla sezione precedente e assicuratevi
355    di aver fatto una copia di riserva totale della cartella GnuPG. Quello
356    che stiamo per fare renderà la vostra chiave inutile se non avete delle
357    copie di riserva utilizzabili!
358
359Per prima cosa, identificate il keygrip della vostra chiave primaria::
360
361    $ gpg --with-keygrip --list-key [fpr]
362
363L'output assomiglierà a questo::
364
365    pub   rsa2048 2018-01-24 [SC] [expires: 2020-01-24]
366          000000000000000000000000AAAABBBBCCCCDDDD
367          Keygrip = 1111000000000000000000000000000000000000
368    uid           [ultimate] Alice Dev <adev@kernel.org>
369    sub   rsa2048 2018-01-24 [E] [expires: 2020-01-24]
370          Keygrip = 2222000000000000000000000000000000000000
371    sub   ed25519 2018-01-24 [S]
372          Keygrip = 3333000000000000000000000000000000000000
373
374Trovate la voce keygrid che si trova sotto alla riga ``pub`` (appena sotto
375all'impronta digitale della chiave primaria). Questo corrisponderà direttamente
376ad un file nella cartella ``~/.gnupg``::
377
378    $ cd ~/.gnupg/private-keys-v1.d
379    $ ls
380    1111000000000000000000000000000000000000.key
381    2222000000000000000000000000000000000000.key
382    3333000000000000000000000000000000000000.key
383
384Quello che dovrete fare è rimuovere il file .key che corrisponde al keygrip
385della chiave primaria::
386
387    $ cd ~/.gnupg/private-keys-v1.d
388    $ rm 1111000000000000000000000000000000000000.key
389
390Ora, se eseguite il comando ``--list-secret-keys``, vedrete che la chiave
391primaria non compare più (il simbolo ``#`` indica che non è disponibile)::
392
393    $ gpg --list-secret-keys
394    sec#  rsa2048 2018-01-24 [SC] [expires: 2020-01-24]
395          000000000000000000000000AAAABBBBCCCCDDDD
396    uid           [ultimate] Alice Dev <adev@kernel.org>
397    ssb   rsa2048 2018-01-24 [E] [expires: 2020-01-24]
398    ssb   ed25519 2018-01-24 [S]
399
400Dovreste rimuovere anche i file ``secring.gpg`` che si trovano nella cartella
401``~/.gnupg``, in quanto rimasugli delle versioni precedenti di GnuPG.
402
403Se non avete la cartella "private-keys-v1.d"
404~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
405
406Se non avete la cartella ``~/.gnupg/private-keys-v1.d``, allora le vostre
407chiavi segrete sono ancora salvate nel vecchio file ``secring.gpg`` usato
408da GnuPG v1. Effettuare una qualsiasi modifica alla vostra chiave, come
409cambiare la passphare o aggiungere una sottochiave, dovrebbe convertire
410automaticamente il vecchio formato ``secring.gpg``nel nuovo
411``private-keys-v1.d``.
412
413Una volta che l'avete fatto, assicuratevi di rimuovere il file ``secring.gpg``,
414che continua a contenere la vostra chiave privata.
415
416.. _it_smartcards:
417
418Spostare le sottochiavi in un apposito dispositivo criptato
419===========================================================
420
421Nonostante la chiave primaria sia ora al riparo da occhi e mani indiscrete,
422le sottochiavi si trovano ancora nella vostra cartella home. Chiunque riesca
423a mettere le sue mani su quelle chiavi riuscirà a decriptare le vostre
424comunicazioni o a falsificare le vostre firme (se conoscono la passphrase).
425Inoltre, ogni volta che viene fatta un'operazione con GnuPG, le chiavi vengono
426caricate nella memoria di sistema e potrebbero essere rubate con l'uso di
427malware sofisticati (pensate a Meltdown e a Spectre).
428
429Il miglior modo per proteggere le proprie chiave è di spostarle su un
430dispositivo specializzato in grado di effettuare operazioni smartcard.
431
432I benefici di una smartcard
433---------------------------
434
435Una smartcard contiene un chip crittografico che è capace di immagazzinare
436le chiavi private ed effettuare operazioni crittografiche direttamente sulla
437carta stessa. Dato che la chiave non lascia mai la smartcard, il sistema
438operativo usato sul computer non sarà in grado di accedere alle chiavi.
439Questo è molto diverso dai dischi USB criptati che abbiamo usato allo scopo di
440avere una copia di riserva sicura -- quando il dispositivo USB è connesso e
441montato, il sistema operativo potrà accedere al contenuto delle chiavi private.
442
443L'uso di un disco USB criptato non può sostituire le funzioni di un dispositivo
444capace di operazioni di tipo smartcard.
445
446Dispositivi smartcard disponibili
447---------------------------------
448
449A meno che tutti i vostri computer dispongano di lettori smartcard, il modo
450più semplice è equipaggiarsi di un dispositivo USB specializzato che
451implementi le funzionalità delle smartcard.  Sul mercato ci sono diverse
452soluzioni disponibili:
453
454- `Nitrokey Start`_: è Open hardware e Free Software, è basata sul progetto
455  `GnuK`_ della FSIJ. Questo è uno dei pochi dispositivi a supportare le chiavi
456  ECC ED25519, ma offre meno funzionalità di sicurezza (come la resistenza
457  alla manomissione o alcuni attacchi ad un canale laterale).
458- `Nitrokey Pro 2`_: è simile alla Nitrokey Start, ma è più resistente alla
459  manomissione e offre più funzionalità di sicurezza. La Pro 2 supporta la
460  crittografia ECC (NISTP).
461- `Yubikey 5`_: l'hardware e il software sono proprietari, ma è più economica
462  della  Nitrokey Pro ed è venduta anche con porta USB-C il che è utile con i
463  computer portatili più recenti. In aggiunta, offre altre funzionalità di
464  sicurezza come FIDO, U2F, e ora supporta anche le chiavi ECC (NISTP)
465
466`Su LWN c'è una buona recensione`_ dei modelli elencati qui sopra e altri.
467La scelta dipenderà dal costo, dalla disponibilità nella vostra area
468geografica e vostre considerazioni sull'hardware aperto/proprietario.
469
470Se volete usare chiavi ECC, la vostra migliore scelta sul mercato è la
471Nitrokey Start.
472
473.. _`Nitrokey Start`: https://shop.nitrokey.com/shop/product/nitrokey-start-6
474.. _`Nitrokey Pro 2`: https://shop.nitrokey.com/shop/product/nitrokey-pro-2-3
475.. _`Yubikey 5`: https://www.yubico.com/product/yubikey-5-overview/
476.. _Gnuk: http://www.fsij.org/doc-gnuk/
477.. _`Su LWN c'è una buona recensione`: https://lwn.net/Articles/736231/
478
479Configurare il vostro dispositivo smartcard
480-------------------------------------------
481
482Il vostro dispositivo smartcard dovrebbe iniziare a funzionare non appena
483lo collegate ad un qualsiasi computer Linux moderno. Potete verificarlo
484eseguendo::
485
486    $ gpg --card-status
487
488Se vedete tutti i dettagli della smartcard, allora ci siamo. Sfortunatamente,
489affrontare tutti i possibili motivi per cui le cose potrebbero non funzionare
490non è lo scopo di questa guida. Se avete problemi nel far funzionare la carta
491con GnuPG, cercate aiuto attraverso i soliti canali di supporto.
492
493Per configurare la vostra smartcard, dato che non c'è una via facile dalla
494riga di comando, dovrete usate il menu di GnuPG::
495
496    $ gpg --card-edit
497    [...omitted...]
498    gpg/card> admin
499    Admin commands are allowed
500    gpg/card> passwd
501
502Dovreste impostare il PIN dell'utente (1), quello dell'amministratore (3) e il
503codice di reset (4). Assicuratevi di annotare e salvare questi codici in un
504posto sicuro -- specialmente il PIN dell'amministratore e il codice di reset
505(che vi permetterà di azzerare completamente la smartcard).  Il PIN
506dell'amministratore viene usato così raramente che è inevitabile dimenticarselo
507se non lo si annota.
508
509Tornando al nostro menu, potete impostare anche altri valori (come il nome,
510il sesso, informazioni d'accesso, eccetera), ma non sono necessari e aggiunge
511altre informazioni sulla carta che potrebbero trapelare in caso di smarrimento.
512
513.. note::
514
515    A dispetto del nome "PIN", né il PIN utente né quello dell'amministratore
516    devono essere esclusivamente numerici.
517
518Spostare le sottochiavi sulla smartcard
519---------------------------------------
520
521Uscite dal menu (usando "q") e salverete tutte le modifiche. Poi, spostiamo
522tutte le sottochiavi sulla smartcard. Per la maggior parte delle operazioni
523vi serviranno sia la passphrase della chiave PGP che il PIN
524dell'amministratore::
525
526    $ gpg --edit-key [fpr]
527
528    Secret subkeys are available.
529
530    pub  rsa2048/AAAABBBBCCCCDDDD
531         created: 2018-01-23  expires: 2020-01-23  usage: SC
532         trust: ultimate      validity: ultimate
533    ssb  rsa2048/1111222233334444
534         created: 2018-01-23  expires: never       usage: E
535    ssb  ed25519/5555666677778888
536         created: 2017-12-07  expires: never       usage: S
537    [ultimate] (1). Alice Dev <adev@kernel.org>
538
539    gpg>
540
541Usando ``--edit-key`` si tornerà alla modalità menu e noterete che
542la lista delle chiavi è leggermente diversa. Da questo momento in poi,
543tutti i comandi saranno eseguiti nella modalità menu, come indicato
544da ``gpg>``.
545
546Per prima cosa, selezioniamo la chiave che verrà messa sulla carta --
547potete farlo digitando ``key 1`` (è la prima della lista, la sottochiave
548**[E]**)::
549
550    gpg> key 1
551
552Nel'output dovreste vedere ``ssb*`` associato alla chiave **[E]**. Il simbolo
553``*`` indica che la chiave è stata "selezionata". Funziona come un
554interruttore, ovvero se scrivete nuovamente ``key 1``, il simbolo ``*`` sparirà
555e la chiave non sarà più selezionata.
556
557Ora, spostiamo la chiave sulla smartcard::
558
559    gpg> keytocard
560    Please select where to store the key:
561       (2) Encryption key
562    Your selection? 2
563
564Dato che è la nostra chiave  **[E]**, ha senso metterla nella sezione criptata.
565Quando confermerete la selezione, vi verrà chiesta la passphrase della vostra
566chiave PGP, e poi il PIN dell'amministratore. Se il comando ritorna senza
567errori, allora la vostra chiave è stata spostata con successo.
568
569**Importante**: digitate nuovamente ``key 1`` per deselezionare la prima chiave
570e selezionate la seconda chiave **[S]** con ``key 2``::
571
572    gpg> key 1
573    gpg> key 2
574    gpg> keytocard
575    Please select where to store the key:
576       (1) Signature key
577       (3) Authentication key
578    Your selection? 1
579
580Potete usare la chiave **[S]** sia per firmare che per autenticare, ma vogliamo
581che sia nella sezione di firma, quindi scegliete (1). Ancora una volta, se il
582comando ritorna senza errori, allora l'operazione è avvenuta con successo::
583
584    gpg> q
585    Save changes? (y/N) y
586
587Salvando le modifiche cancellerete dalla vostra cartella home tutte le chiavi
588che avete spostato sulla carta (ma questo non è un problema, perché abbiamo
589fatto delle copie di sicurezza nel caso in cui dovessimo configurare una
590nuova smartcard).
591
592Verificare che le chiavi siano state spostate
593~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
594
595Ora, se doveste usare l'opzione ``--list-secret-keys``, vedrete una
596sottile differenza nell'output::
597
598    $ gpg --list-secret-keys
599    sec#  rsa2048 2018-01-24 [SC] [expires: 2020-01-24]
600          000000000000000000000000AAAABBBBCCCCDDDD
601    uid           [ultimate] Alice Dev <adev@kernel.org>
602    ssb>  rsa2048 2018-01-24 [E] [expires: 2020-01-24]
603    ssb>  ed25519 2018-01-24 [S]
604
605Il simbolo ``>`` in ``ssb>`` indica che la sottochiave è disponibile solo
606nella smartcard. Se tornate nella vostra cartella delle chiavi segrete e
607guardate al suo contenuto, noterete che i file ``.key`` sono stati sostituiti
608con degli stub::
609
610    $ cd ~/.gnupg/private-keys-v1.d
611    $ strings *.key | grep 'private-key'
612
613Per indicare che i file sono solo degli stub e che in realtà il contenuto è
614sulla smartcard, l'output dovrebbe mostrarvi ``shadowed-private-key``.
615
616Verificare che la smartcard funzioni
617~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
618
619Per verificare che la smartcard funzioni come dovuto, potete creare
620una firma::
621
622    $ echo "Hello world" | gpg --clearsign > /tmp/test.asc
623    $ gpg --verify /tmp/test.asc
624
625Col primo comando dovrebbe chiedervi il PIN della smartcard, e poi dovrebbe
626mostrare "Good signature" dopo l'esecuzione di ``gpg --verify``.
627
628Complimenti, siete riusciti a rendere estremamente difficile il furto della
629vostra identità digitale di sviluppatore.
630
631Altre operazioni possibili con GnuPG
632------------------------------------
633
634Segue un breve accenno ad alcune delle operazioni più comuni che dovrete
635fare con le vostre chiavi PGP.
636
637Montare il disco con la chiave primaria
638~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
639
640Vi servirà la vostra chiave principale per tutte le operazioni che seguiranno,
641per cui per prima cosa dovrete accedere ai vostri backup e dire a GnuPG di
642usarli::
643
644    $ export GNUPGHOME=/media/disk/foo/gnupg-backup
645    $ gpg --list-secret-keys
646
647Dovete assicurarvi di vedere ``sec`` e non ``sec#`` nell'output del programma
648(il simbolo ``#`` significa che la chiave non è disponibile e che state ancora
649utilizzando la vostra solita cartella di lavoro).
650
651Estendere la data di scadenza di una chiave
652~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
653
654La chiave principale ha una data di scadenza di 2 anni dal momento della sua
655creazione. Questo per motivi di sicurezza e per rendere obsolete le chiavi
656che, eventualmente, dovessero sparire dai keyserver.
657
658Per estendere di un anno, dalla data odierna, la scadenza di una vostra chiave,
659eseguite::
660
661    $ gpg --quick-set-expire [fpr] 1y
662
663Se per voi è più facile da memorizzare, potete anche utilizzare una data
664specifica (per esempio, il vostro compleanno o capodanno)::
665
666    $ gpg --quick-set-expire [fpr] 2020-07-01
667
668Ricordatevi di inviare l'aggiornamento ai keyserver::
669
670    $ gpg --send-key [fpr]
671
672Aggiornare la vostra cartella di lavoro dopo ogni modifica
673~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
674
675Dopo aver fatto delle modifiche alle vostre chiavi usando uno spazio a parte,
676dovreste importarle nella vostra cartella di lavoro abituale::
677
678    $ gpg --export | gpg --homedir ~/.gnupg --import
679    $ unset GNUPGHOME
680
681
682Usare PGP con Git
683=================
684
685Una delle caratteristiche fondanti di Git è la sua natura decentralizzata --
686una volta che il repositorio è stato clonato sul vostro sistema, avete la
687storia completa del progetto, inclusi i suoi tag, i commit ed i rami. Tuttavia,
688con i centinaia di repositori clonati che ci sono in giro, come si fa a
689verificare che la loro copia di linux.git non è stata manomessa da qualcuno?
690
691Oppure, cosa succede se viene scoperta una backdoor nel codice e la riga
692"Autore" dice che sei stato tu, mentre tu sei abbastanza sicuro di
693`non averci niente a che fare`_?
694
695Per risolvere entrambi i problemi, Git ha introdotto l'integrazione con PGP.
696I tag firmati dimostrano che il repositorio è integro assicurando che il suo
697contenuto è lo stesso che si trova sulle macchine degli sviluppatori che hanno
698creato il tag; mentre i commit firmati rendono praticamente impossibile
699ad un malintenzionato di impersonarvi senza avere accesso alle vostre chiavi
700PGP.
701
702.. _`non averci niente a che fare`: https://github.com/jayphelps/git-blame-someone-else
703
704Configurare git per usare la vostra chiave PGP
705----------------------------------------------
706
707Se avete solo una chiave segreta nel vostro portachiavi, allora non avete nulla
708da fare in più dato che sarà la vostra chiave di base. Tuttavia, se doveste
709avere più chiavi segrete, potete dire a git quale dovrebbe usare (``[fpg]``
710è la vostra impronta digitale)::
711
712    $ git config --global user.signingKey [fpr]
713
714**IMPORTANTE**: se avete una comando dedicato per ``gpg2``, allora dovreste
715dire a git di usare sempre quello piuttosto che il vecchio comando ``gpg``::
716
717    $ git config --global gpg.program gpg2
718
719Come firmare i tag
720------------------
721
722Per creare un tag firmato, passate l'opzione ``-s`` al comando tag::
723
724    $ git tag -s [tagname]
725
726La nostra raccomandazione è quella di firmare sempre i tag git, perché
727questo permette agli altri sviluppatori di verificare che il repositorio
728git dal quale stanno prendendo il codice non è stato alterato intenzionalmente.
729
730Come verificare i tag firmati
731~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
732
733Per verificare un tag firmato, potete usare il comando ``verify-tag``::
734
735    $ git verify-tag [tagname]
736
737Se state prendendo un tag da un fork del repositorio del progetto, git
738dovrebbe verificare automaticamente la firma di quello che state prendendo
739e vi mostrerà il risultato durante l'operazione di merge::
740
741    $ git pull [url] tags/sometag
742
743Il merge conterrà qualcosa di simile::
744
745    Merge tag 'sometag' of [url]
746
747    [Tag message]
748
749    # gpg: Signature made [...]
750    # gpg: Good signature from [...]
751
752Se state verificando il tag di qualcun altro, allora dovrete importare
753la loro chiave PGP. Fate riferimento alla sezione ":ref:`it_verify_identities`"
754che troverete più avanti.
755
756Configurare git per firmare sempre i tag con annotazione
757~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
758
759Se state creando un tag con annotazione è molto probabile che vogliate
760firmarlo. Per imporre a git di firmare sempre un tag con annotazione,
761dovete impostare la seguente opzione globale::
762
763    $ git config --global tag.forceSignAnnotated true
764
765Come usare commit firmati
766-------------------------
767
768Creare dei commit firmati è facile, ma è molto più difficile utilizzarli
769nello sviluppo del kernel linux per via del fatto che ci si affida alle
770liste di discussione e questo modo di procedere non mantiene le firme PGP
771nei commit. In aggiunta, quando si usa *rebase* nel proprio repositorio
772locale per allinearsi al kernel anche le proprie firme PGP verranno scartate.
773Per questo motivo, la maggior parte degli sviluppatori del kernel non si
774preoccupano troppo di firmare i propri commit ed ignoreranno quelli firmati
775che si trovano in altri repositori usati per il proprio lavoro.
776
777Tuttavia, se avete il vostro repositorio di lavoro disponibile al pubblico
778su un qualche servizio di hosting git (kernel.org, infradead.org, ozlabs.org,
779o altri), allora la raccomandazione è di firmare tutti i vostri commit
780anche se gli sviluppatori non ne beneficeranno direttamente.
781
782Vi raccomandiamo di farlo per i seguenti motivi:
783
7841. Se dovesse mai esserci la necessità di fare delle analisi forensi o
785   tracciare la provenienza di un codice, anche sorgenti mantenuti
786   esternamente che hanno firme PGP sui commit avranno un certo valore a
787   questo scopo.
7882. Se dovesse mai capitarvi di clonare il vostro repositorio locale (per
789   esempio dopo un danneggiamento del disco), la firma vi permetterà di
790   verificare l'integrità del repositorio prima di riprendere il lavoro.
7913. Se qualcuno volesse usare *cherry-pick* sui vostri commit, allora la firma
792   permetterà di verificare l'integrità dei commit prima di applicarli.
793
794Creare commit firmati
795~~~~~~~~~~~~~~~~~~~~~
796
797Per creare un commit firmato, dovete solamente aggiungere l'opzione ``-S``
798al comando ``git commit`` (si usa la lettera maiuscola per evitare
799conflitti con un'altra opzione)::
800
801    $ git commit -S
802
803Configurare git per firmare sempre i commit
804~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
805
806Potete dire a git di firmare sempre i commit::
807
808    git config --global commit.gpgSign true
809
810.. note::
811
812    Assicuratevi di aver configurato ``gpg-agent`` prima di abilitare
813    questa opzione.
814
815.. _it_verify_identities:
816
817Come verificare l'identità degli sviluppatori del kernel
818========================================================
819
820Firmare i tag e i commit è facile, ma come si fa a verificare che la chiave
821usata per firmare qualcosa appartenga davvero allo sviluppatore e non ad un
822impostore?
823
824Configurare l'auto-key-retrieval usando WKD e DANE
825--------------------------------------------------
826
827Se non siete ancora in possesso di una vasta collezione di chiavi pubbliche
828di altri sviluppatori, allora potreste iniziare il vostro portachiavi
829affidandovi ai servizi di auto-scoperta e auto-recupero. GnuPG può affidarsi
830ad altre tecnologie di delega della fiducia, come DNSSEC e TLS, per sostenervi
831nel caso in cui iniziare una propria rete di fiducia da zero sia troppo
832scoraggiante.
833
834Aggiungete il seguente testo al vostro file ``~/.gnupg/gpg.conf``::
835
836    auto-key-locate wkd,dane,local
837    auto-key-retrieve
838
839La *DNS-Based Authentication of Named Entities* ("DANE") è un metodo
840per la pubblicazione di chiavi pubbliche su DNS e per renderle sicure usando
841zone firmate con DNSSEC. Il *Web Key Directory* ("WKD") è un metodo
842alternativo che usa https a scopo di ricerca. Quando si usano DANE o WKD
843per la ricerca di chiavi pubbliche, GnuPG validerà i certificati DNSSEC o TLS
844prima di aggiungere al vostro portachiavi locale le eventuali chiavi trovate.
845
846Kernel.org pubblica la WKD per tutti gli sviluppatori che hanno un account
847kernel.org. Una volta che avete applicato le modifiche al file ``gpg.conf``,
848potrete auto-recuperare le chiavi di Linus Torvalds e Greg Kroah-Hartman
849(se non le avete già)::
850
851    $ gpg --locate-keys torvalds@kernel.org gregkh@kernel.org
852
853Se avete un account kernel.org, al fine di rendere più utile l'uso di WKD
854da parte di altri sviluppatori del kernel, dovreste `aggiungere alla vostra
855chiave lo UID di kernel.org`_.
856
857.. _`aggiungere alla vostra chiave lo UID di kernel.org`: https://korg.wiki.kernel.org/userdoc/mail#adding_a_kernelorg_uid_to_your_pgp_key
858
859Web of Trust (WOT) o Trust on First Use (TOFU)
860----------------------------------------------
861
862PGP incorpora un meccanismo di delega della fiducia conosciuto come
863"Web of Trust". Di base, questo è un tentativo di sostituire la necessità
864di un'autorità certificativa centralizzata tipica del mondo HTTPS/TLS.
865Invece di avere svariati produttori software che decidono chi dovrebbero
866essere le entità di certificazione di cui dovreste fidarvi, PGP lascia
867la responsabilità ad ogni singolo utente.
868
869Sfortunatamente, solo poche persone capiscono come funziona la rete di fiducia.
870Nonostante sia un importante aspetto della specifica OpenPGP, recentemente
871le versioni di GnuPG (2.2 e successive) hanno implementato un meccanisco
872alternativo chiamato "Trust on First Use" (TOFU). Potete pensare a TOFU come
873"ad un approccio all fidicia simile ad SSH". In SSH, la prima volta che vi
874connettete ad un sistema remoto, l'impronta digitale della chiave viene
875registrata e ricordata. Se la chiave dovesse cambiare in futuro, il programma
876SSH vi avviserà e si rifiuterà di connettersi, obbligandovi a prendere una
877decisione circa la fiducia che riponete nella nuova chiave. In modo simile,
878la prima volta che importate la chiave PGP di qualcuno, si assume sia valida.
879Se ad un certo punto GnuPG trova un'altra chiave con la stessa identità,
880entrambe, la vecchia e la nuova, verranno segnate come invalide e dovrete
881verificare manualmente quale tenere.
882
883Vi raccomandiamo di usare il meccanisco TOFU+PGP (che è la nuova configurazione
884di base di GnuPG v2). Per farlo, aggiungete (o modificate) l'impostazione
885``trust-model`` in ``~/.gnupg/gpg.conf``::
886
887    trust-model tofu+pgp
888
889Come usare i keyserver in sicurezza
890-----------------------------------
891Se ottenete l'errore "No public key" quando cercate di validate il tag di
892qualcuno, allora dovreste cercare quella chiave usando un keyserver. È
893importante tenere bene a mente che non c'è alcuna garanzia che la chiave
894che avete recuperato da un keyserver PGP appartenga davvero alla persona
895reale -- è progettato così. Dovreste usare il Web of Trust per assicurarvi
896che la chiave sia valida.
897
898Come mantenere il Web of Trust va oltre gli scopi di questo documento,
899semplicemente perché farlo come si deve richiede sia sforzi che perseveranza
900che tendono ad andare oltre al livello di interesse della maggior parte degli
901esseri umani. Qui di seguito alcuni rapidi suggerimenti per aiutarvi a ridurre
902il rischio di importare chiavi maligne.
903
904Primo, diciamo che avete provato ad eseguire ``git verify-tag`` ma restituisce
905un errore dicendo che la chiave non è stata trovata::
906
907    $ git verify-tag sunxi-fixes-for-4.15-2
908    gpg: Signature made Sun 07 Jan 2018 10:51:55 PM EST
909    gpg:                using RSA key DA73759BF8619E484E5A3B47389A54219C0F2430
910    gpg:                issuer "wens@...org"
911    gpg: Can't check signature: No public key
912
913Cerchiamo nel keyserver per maggiori informazioni sull'impronta digitale
914della chiave (l'impronta digitale, probabilmente, appartiene ad una
915sottochiave, dunque non possiamo usarla direttamente senza trovare prima
916l'ID della chiave primaria associata ad essa)::
917
918    $ gpg --search DA73759BF8619E484E5A3B47389A54219C0F2430
919    gpg: data source: hkp://keys.gnupg.net
920    (1) Chen-Yu Tsai <wens@...org>
921          4096 bit RSA key C94035C21B4F2AEB, created: 2017-03-14, expires: 2019-03-15
922    Keys 1-1 of 1 for "DA73759BF8619E484E5A3B47389A54219C0F2430".  Enter number(s), N)ext, or Q)uit > q
923
924Localizzate l'ID della chiave primaria, nel nostro esempio
925``C94035C21B4F2AEB``. Ora visualizzate le chiavi di Linus Torvalds
926che avete nel vostro portachiavi::
927
928    $ gpg --list-key torvalds@kernel.org
929    pub   rsa2048 2011-09-20 [SC]
930          ABAF11C65A2970B130ABE3C479BE3E4300411886
931    uid           [ unknown] Linus Torvalds <torvalds@kernel.org>
932    sub   rsa2048 2011-09-20 [E]
933
934Poi, aprite il `PGP pathfinder`_. Nel campo "From", incollate l'impronta
935digitale della chiave di Linus Torvalds che si vede nell'output qui sopra.
936Nel campo "to", incollate il key-id della chiave sconosciuta che avete
937trovato con ``gpg --search``, e poi verificare il risultato:
938
939- `Finding paths to Linus`_
940
941Se trovate un paio di percorsi affidabili è un buon segno circa la validità
942della chiave. Ora, potete aggiungerla al vostro portachiavi dal keyserver::
943
944    $ gpg --recv-key C94035C21B4F2AEB
945
946Questa procedura non è perfetta, e ovviamente state riponendo la vostra
947fiducia nell'amministratore del servizio *PGP Pathfinder* sperando che non
948sia malintenzionato (infatti, questo va contro :ref:`it_devs_not_infra`).
949Tuttavia, se mantenete con cura la vostra rete di fiducia sarà un deciso
950miglioramento rispetto alla cieca fiducia nei keyserver.
951
952.. _`PGP pathfinder`: https://pgp.cs.uu.nl/
953.. _`Finding paths to Linus`: https://pgp.cs.uu.nl/paths/79BE3E4300411886/to/C94035C21B4F2AEB.html
954