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