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 =========================================
9 La guida a PGP per manutentori del kernel
10 =========================================
11
12 :Author: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
13
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
20
21 .. _`Protecting Code Integrity`: https://github.com/lfit/itpol/blob/master/protecting-code-integrity.md
22
23 Il ruolo di PGP nello sviluppo del kernel Linux
24 ===============================================
25
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.
29
30 Il codice sorgente del kernel Linux è disponibile principalmente in due
31 formati:
32
33 - repositori distribuiti di sorgenti (git)
34 - rilasci periodici di istantanee (archivi tar)
35
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:
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
47 Fidatevi degli sviluppatori e non dell'infrastruttura
48 -----------------------------------------------------
49
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.
57
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
64 stesso.
65
66 .. _it_pgp_tools:
67
68 Strumenti PGP
69 =============
70
71 Usare GnuPG 2.2 o successivo
72 ----------------------------
73
74 La vostra distribuzione potrebbe avere già installato GnuPG, dovete solo
75 verificare che stia utilizzando la versione abbastanza recente. Per controllate
76 usate::
77
78 $ gpg --version | head -n1
79
80 Se state utilizzando la version 2.2 o successiva, allora siete pronti a partire.
81 Se invece state usando una versione precedente, allora alcuni comandi elencati
82 in questa guida potrebbero non funzionare.
83
84 Configurare le opzioni di gpg-agent
85 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
86
87 L'agente GnuPG è uno strumento di aiuto che partirà automaticamente ogni volta
88 che userete il comando ``gpg`` e funzionerà in *background* con l'obiettivo di
89 individuare la passphrase. Ci sono due opzioni che dovreste conoscere
90 per personalizzare la scadenza della passphrase nella cache:
91
92 - ``default-cache-ttl`` (secondi): Se usate ancora la stessa chiave prima
93 che il time-to-live termini, il conto alla rovescia si resetterà per un
94 altro periodo. Di base è di 600 (10 minuti).
95
96 - ``max-cache-ttl`` (secondi): indipendentemente da quanto sia recente l'ultimo
97 uso della chiave da quando avete inserito la passphrase, se il massimo
98 time-to-live è scaduto, dovrete reinserire nuovamente la passphrase.
99 Di base è di 30 minuti.
100
101 Se ritenete entrambe questi valori di base troppo corti (o troppo lunghi),
102 potete creare il vostro file ``~/.gnupg/gpg-agent.conf`` ed impostare i vostri
103 valori::
104
105 # set to 30 minutes for regular ttl, and 2 hours for max ttl
106 default-cache-ttl 1800
107 max-cache-ttl 7200
108
109 .. note::
110
111 Non è più necessario far partire l'agente gpg manualmente all'inizio della
112 vostra sessione. Dovreste controllare i file rc per rimuovere tutto ciò che
113 riguarda vecchie le versioni di GnuPG, poiché potrebbero non svolgere più
114 bene il loro compito.
115
116 .. _it_protect_your_key:
117
118 Proteggere la vostra chiave PGP primaria
119 ========================================
120
121 Questa guida parte dal presupposto che abbiate già una chiave PGP che usate
122 per lo sviluppo del kernel Linux. Se non ne avete ancora una, date uno sguardo
123 al documento "`Protecting Code Integrity`_" che abbiamo menzionato prima.
124
125 Dovreste inoltre creare una nuova chiave se quella attuale è inferiore a 2048
126 bit (RSA).
127
128 Le sottochiavi PGP
129 ------------------
130
131 Raramente le chiavi PGP sono composte da una singola coppia -- solitamente, sono
132 una collezione di sottochiavi indipendenti usate per diversi scopi in funzione
133 delle capacità assegnate al momento della creazione. Una chiave PGP può avere
134 quattro capacità:
135
136 - **[S]** può essere usata per firmare
137 - **[E]** può essere usata per criptare
138 - **[A]** può essere usata per autenticare
139 - **[C]** può essere usata per certificare altre chiavi
140
141 La chiave con la capacità **[C]** viene spesso chiamata chiave "passepartout"
142 (*master key*), ma è una terminologia fuorviante perché lascia intendere che la
143 chiave di certificato possa essere usate in sostituzione delle altre (proprio
144 come le vere chiavi passpartout in grado di aprire diverse serrature). Dato che
145 questo non è il caso, per evitare fraintendimenti, in questa guida ci riferiremo
146 a questa chiave chiamandola "La chiave di certificazione".
147
148 I seguenti punti sono molto importanti:
149
150 1. Tutte le sottochiavi sono indipendenti. Se perdete una sottochiave privata
151 non potrete recuperarla usando le altre.
152 2. Ad eccezione della chiave di certificazione, ci possono essere più
153 sottochiavi con le stesse capacità (per esempio, potete avere 2 sottochiavi
154 per criptare, 3 per firmare, ma solo una per una sola per certificare). Tutte
155 le sottochiavi sono indipendenti -- un messaggio criptato usando una chiave
156 **[E]** non può essere decriptato usano altre sottochiavi **[E]**.
157 3. Una sottochiave può avere più capacità (per esempio, la chiave **[C]** può
158 anche essere una chiave **[S]**).
159
160 La chiave con capacità **[C]** (certificazione) è la sola che può essere usata
161 per indicare relazioni fra chiavi. Solo la chiave **[C]** può essere usata per:
162
163 - aggiungere o revocare altre chiavi (sottochiavi) che hanno capacità S/E/A;
164 - aggiungere, modificare o eliminare le identità (unids) associate alla chiave;
165 - aggiungere o modificare la propria data di scadenza o delle sottochiavi;
166 - firmare le chiavi di altre persone a scopo di creare una rete di fiducia.
167
168 Di base, alla creazione di nuove chiavi, GnuPG genera quanto segue:
169
170 - Una chiave la capacità di certificazione che quella di firma (**[SC]**)
171 - Una sottochiave separata con capacità di criptare (**[E]**)
172
173
174
175
176 Se avete usato i parametri predefiniti per generare la vostra chiave, quello
177 sarà il risultato. Potete verificarlo utilizzando ``gpg --list-secret-keys``,
178 per esempio::
179
180 sec ed25519 2022-12-20 [SC] [expires: 2024-12-19]
181 000000000000000000000000AAAABBBBCCCCDDDD
182 uid [ultimate] Alice Dev <adev@kernel.org>
183 ssb cv25519 2022-12-20 [E] [expires: 2024-12-19]
184
185 La lunga riga sotto la voce ``sec`` è la vostra impronta digitale --
186 negli esempi che seguono, quando vedere ``[fpr]`` ci si riferisce a questa
187 stringa di 40 caratteri.
188
189 Assicuratevi che la vostra passphrase sia forte
190 -----------------------------------------------
191
192 GnuPG utilizza le passphrases per criptare la vostra chiave privata prima
193 di salvarla sul disco. In questo modo, anche se il contenuto della vostra
194 cartella ``.gnupg`` venisse letto o trafugato nella sia interezza, gli
195 attaccanti non potrebbero comunque utilizzare le vostre chiavi private senza
196 aver prima ottenuto la passphrase per decriptarle.
197
198 È assolutamente essenziale che le vostre chiavi private siano protette da
199 una passphrase forte. Per impostarla o cambiarla, usate::
200
201 $ gpg --change-passphrase [fpr]
202
203 Create una sottochiave di firma separata
204 ----------------------------------------
205
206 Il nostro obiettivo è di proteggere la chiave primaria spostandola su un
207 dispositivo sconnesso dalla rete, dunque se avete solo una chiave combinata
208 **[SC]** allora dovreste creare una sottochiave di firma separata::
209
210 $ gpg --quick-add-key [fpr] ed25519 sign
211
212 Ricordate di informare il keyserver del vostro cambiamento, cosicché altri
213 possano ricevere la vostra nuova sottochiave::
214
215 $ gpg --send-key [fpr]
216
217 .. note:: Supporto ECC in GnuPG
218
219 Tenete presente che se avete intenzione di usare un dispositivo che non
220 supporta chiavi ED25519 ECC, allora dovreste usare "nistp256" al posto di
221 "ed25519". Più avanti ci sono alcune raccomandazioni per i dispositivi.
222
223 Copia di riserva della chiave primaria per gestire il recupero da disastro
224 --------------------------------------------------------------------------
225
226 Maggiori sono le firme di altri sviluppatori che vengono applicate alla vostra,
227 maggiori saranno i motivi per avere una copia di riserva che non sia digitale,
228 al fine di effettuare un recupero da disastro.
229
230 Il modo migliore per creare una copia fisica della vostra chiave privata è
231 l'uso del programma ``paperkey``. Consultate ``man paperkey`` per maggiori
232 dettagli sul formato dell'output ed i suoi punti di forza rispetto ad altre
233 soluzioni. Paperkey dovrebbe essere già pacchettizzato per la maggior parte
234 delle distribuzioni.
235
236 Eseguite il seguente comando per creare una copia fisica di riserva della
237 vostra chiave privata::
238
239 $ gpg --export-secret-key [fpr] | paperkey -o /tmp/key-backup.txt
240
241 Stampate il file (o fate un pipe direttamente verso lpr), poi prendete
242 una penna e scrivete la passphare sul margine del foglio. **Questo è
243 caldamente consigliato** perché la copia cartacea è comunque criptata con
244 la passphrase, e se mai doveste cambiarla non vi ricorderete qual'era al
245 momento della creazione di quella copia -- *garantito*.
246
247 Mettete la copia cartacea e la passphrase scritta a mano in una busta e
248 mettetela in un posto sicuro e ben protetto, preferibilmente fuori casa,
249 magari in una cassetta di sicurezza in banca.
250
251 .. note::
252
253 Probabilmente la vostra stampante non è più quello stupido dispositivo
254 connesso alla porta parallela, ma dato che il suo output è comunque
255 criptato con la passphrase, eseguire la stampa in un sistema "cloud"
256 moderno dovrebbe essere comunque relativamente sicuro.
257
258 Copia di riserva di tutta la cartella GnuPG
259 -------------------------------------------
260
261 .. warning::
262
263 **!!!Non saltate questo passo!!!**
264
265 Quando avete bisogno di recuperare le vostre chiavi PGP è importante avere
266 una copia di riserva pronta all'uso. Questo sta su un diverso piano di
267 prontezza rispetto al recupero da disastro che abbiamo risolto con
268 ``paperkey``. Vi affiderete a queste copie esterne quando dovreste usare la
269 vostra chiave Certify -- ovvero quando fate modifiche alle vostre chiavi o
270 firmate le chiavi di altre persone ad una conferenza o ad un gruppo d'incontro.
271
272 Incominciate con una piccola chiavetta di memoria USB (preferibilmente due)
273 che userete per le copie di riserva. Dovrete criptarle usando LUKS -- fate
274 riferimento alla documentazione della vostra distribuzione per capire come
275 fare.
276
277 Per la passphrase di criptazione, potete usare la stessa della vostra chiave
278 primaria.
279
280 Una volta che il processo di criptazione è finito, reinserite il disco USB ed
281 assicurativi che venga montato correttamente. Copiate interamente la cartella
282 ``.gnugp`` nel disco criptato::
283
284 $ cp -a ~/.gnupg /media/disk/foo/gnupg-backup
285
286 Ora dovreste verificare che tutto continui a funzionare::
287
288 $ gpg --homedir=/media/disk/foo/gnupg-backup --list-key [fpr]
289
290 Se non vedete errori, allora dovreste avere fatto tutto con successo.
291 Smontate il disco USB, etichettatelo per bene di modo da evitare di
292 distruggerne il contenuto non appena vi serve una chiavetta USB a caso, ed
293 infine mettetelo in un posto sicuro -- ma non troppo lontano, perché vi servirà
294 di tanto in tanto per modificare le identità, aggiungere o revocare
295 sottochiavi, o firmare le chiavi di altre persone.
296
297 Togliete la chiave primaria dalla vostra home
298 ---------------------------------------------
299
300 I file che si trovano nella vostra cartella home non sono poi così ben protetti
301 come potreste pensare. Potrebbero essere letti o trafugati in diversi modi:
302
303 - accidentalmente quando fate una rapida copia della cartella home per
304 configurare una nuova postazione
305 - da un amministratore di sistema negligente o malintenzionato
306 - attraverso copie di riserva insicure
307 - attraverso malware installato in alcune applicazioni (browser, lettori PDF,
308 eccetera)
309 - attraverso coercizione quando attraversate confini internazionali
310
311 Proteggere la vostra chiave con una buona passphare aiuta notevolmente a
312 ridurre i rischi elencati qui sopra, ma le passphrase possono essere scoperte
313 attraverso i keylogger, il shoulder-surfing, o altri modi. Per questi motivi,
314 nella configurazione si raccomanda di rimuove la chiave primaria dalla vostra
315 cartella home e la si archivia su un dispositivo disconnesso.
316
317 .. warning::
318
319 Per favore, fate riferimento alla sezione precedente e assicuratevi
320 di aver fatto una copia di riserva totale della cartella GnuPG. Quello
321 che stiamo per fare renderà la vostra chiave inutile se non avete delle
322 copie di riserva utilizzabili!
323
324 Per prima cosa, identificate il keygrip della vostra chiave primaria::
325
326 $ gpg --with-keygrip --list-key [fpr]
327
328 L'output assomiglierà a questo::
329
330 pub ed25519 2022-12-20 [SC] [expires: 2022-12-19]
331 000000000000000000000000AAAABBBBCCCCDDDD
332 Keygrip = 1111000000000000000000000000000000000000
333 uid [ultimate] Alice Dev <adev@kernel.org>
334 sub cv25519 2022-12-20 [E] [expires: 2022-12-19]
335 Keygrip = 2222000000000000000000000000000000000000
336 sub ed25519 2022-12-20 [S]
337 Keygrip = 3333000000000000000000000000000000000000
338
339 Trovate la voce keygrid che si trova sotto alla riga ``pub`` (appena sotto
340 all'impronta digitale della chiave primaria). Questo corrisponderà direttamente
341 ad un file nella cartella ``~/.gnupg``::
342
343 $ cd ~/.gnupg/private-keys-v1.d
344 $ ls
345 1111000000000000000000000000000000000000.key
346 2222000000000000000000000000000000000000.key
347 3333000000000000000000000000000000000000.key
348
349 Quello che dovrete fare è rimuovere il file .key che corrisponde al keygrip
350 della chiave primaria::
351
352 $ cd ~/.gnupg/private-keys-v1.d
353 $ rm 1111000000000000000000000000000000000000.key
354
355 Ora, se eseguite il comando ``--list-secret-keys``, vedrete che la chiave
356 primaria non compare più (il simbolo ``#`` indica che non è disponibile)::
357
358 $ gpg --list-secret-keys
359 sec# ed25519 2022-12-20 [SC] [expires: 2024-12-19]
360 000000000000000000000000AAAABBBBCCCCDDDD
361 uid [ultimate] Alice Dev <adev@kernel.org>
362 ssb cv25519 2022-12-20 [E] [expires: 2024-12-19]
363 ssb ed25519 2022-12-20 [S]
364
365 Dovreste rimuovere anche i file ``secring.gpg`` che si trovano nella cartella
366 ``~/.gnupg``, in quanto rimasugli delle versioni precedenti di GnuPG.
367
368 Se non avete la cartella "private-keys-v1.d"
369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
370
371 Se non avete la cartella ``~/.gnupg/private-keys-v1.d``, allora le vostre
372 chiavi segrete sono ancora salvate nel vecchio file ``secring.gpg`` usato
373 da GnuPG v1. Effettuare una qualsiasi modifica alla vostra chiave, come
374 cambiare la passphare o aggiungere una sottochiave, dovrebbe convertire
375 automaticamente il vecchio formato ``secring.gpg``nel nuovo
376 ``private-keys-v1.d``.
377
378 Una volta che l'avete fatto, assicuratevi di rimuovere il file ``secring.gpg``,
379 che continua a contenere la vostra chiave privata.
380
381 .. _it_smartcards:
382
383 Spostare le sottochiavi in un apposito dispositivo criptato
384 ===========================================================
385
386 Nonostante la chiave primaria sia ora al riparo da occhi e mani indiscrete,
387 le sottochiavi si trovano ancora nella vostra cartella home. Chiunque riesca
388 a mettere le sue mani su quelle chiavi riuscirà a decriptare le vostre
389 comunicazioni o a falsificare le vostre firme (se conoscono la passphrase).
390 Inoltre, ogni volta che viene fatta un'operazione con GnuPG, le chiavi vengono
391 caricate nella memoria di sistema e potrebbero essere rubate con l'uso di
392 malware sofisticati (pensate a Meltdown e a Spectre).
393
394 Il miglior modo per proteggere le proprie chiave è di spostarle su un
395 dispositivo specializzato in grado di effettuare operazioni smartcard.
396
397 I benefici di una smartcard
398 ---------------------------
399
400 Una smartcard contiene un chip crittografico che è capace di immagazzinare
401 le chiavi private ed effettuare operazioni crittografiche direttamente sulla
402 carta stessa. Dato che la chiave non lascia mai la smartcard, il sistema
403 operativo usato sul computer non sarà in grado di accedere alle chiavi.
404 Questo è molto diverso dai dischi USB criptati che abbiamo usato allo scopo di
405 avere una copia di riserva sicura -- quando il dispositivo USB è connesso e
406 montato, il sistema operativo potrà accedere al contenuto delle chiavi private.
407
408 L'uso di un disco USB criptato non può sostituire le funzioni di un dispositivo
409 capace di operazioni di tipo smartcard.
410
411 Dispositivi smartcard disponibili
412 ---------------------------------
413
414 A meno che tutti i vostri computer dispongano di lettori smartcard, il modo
415 più semplice è equipaggiarsi di un dispositivo USB specializzato che
416 implementi le funzionalità delle smartcard. Sul mercato ci sono diverse
417 soluzioni disponibili:
418
419 - `Nitrokey Start`_: è Open hardware e Free Software, è basata sul progetto
420 `GnuK`_ della FSIJ. Questo è uno dei pochi dispositivi a supportare le chiavi
421 ECC ED25519, ma offre meno funzionalità di sicurezza (come la resistenza
422 alla manomissione o alcuni attacchi ad un canale laterale).
423 - `Nitrokey Pro 2`_: è simile alla Nitrokey Start, ma è più resistente alla
424 manomissione e offre più funzionalità di sicurezza. La Pro 2 supporta la
425 crittografia ECC (NISTP).
426 - `Yubikey 5`_: l'hardware e il software sono proprietari, ma è più economica
427 della Nitrokey Pro ed è venduta anche con porta USB-C il che è utile con i
428 computer portatili più recenti. In aggiunta, offre altre funzionalità di
429 sicurezza come FIDO, U2F, e ora supporta anche le chiavi ECC (NISTP)
430
431 La vostra scelta dipenderà dal costo, la disponibilità nella vostra regione, e
432 sulla scelta fra dispositivi aperti e proprietari.
433
434 .. note::
435
436 Se siete nella lista MAINTAINERS o avete un profilo su kernel.org, allora
437 `potrete avere gratuitamente una Nitrokey Start`_ grazie alla fondazione
438 Linux.
439
440 .. _`Nitrokey Start`: https://shop.nitrokey.com/shop/product/nitrokey-start-6
441 .. _`Nitrokey Pro 2`: https://shop.nitrokey.com/shop/product/nitrokey-pro-2-3
442 .. _`Yubikey 5`: https://www.yubico.com/product/yubikey-5-overview/
443 .. _Gnuk: https://www.fsij.org/doc-gnuk/
444 .. _`potrete avere gratuitamente una Nitrokey Start`: https://www.kernel.org/nitrokey-digital-tokens-for-kernel-developers.html
445
446 Configurare il vostro dispositivo smartcard
447 -------------------------------------------
448
449 Il vostro dispositivo smartcard dovrebbe iniziare a funzionare non appena
450 lo collegate ad un qualsiasi computer Linux moderno. Potete verificarlo
451 eseguendo::
452
453 $ gpg --card-status
454
455 Se vedete tutti i dettagli della smartcard, allora ci siamo. Sfortunatamente,
456 affrontare tutti i possibili motivi per cui le cose potrebbero non funzionare
457 non è lo scopo di questa guida. Se avete problemi nel far funzionare la carta
458 con GnuPG, cercate aiuto attraverso i soliti canali di supporto.
459
460 Per configurare la vostra smartcard, dato che non c'è una via facile dalla
461 riga di comando, dovrete usate il menu di GnuPG::
462
463 $ gpg --card-edit
464 [...omitted...]
465 gpg/card> admin
466 Admin commands are allowed
467 gpg/card> passwd
468
469 Dovreste impostare il PIN dell'utente (1), quello dell'amministratore (3) e il
470 codice di reset (4). Assicuratevi di annotare e salvare questi codici in un
471 posto sicuro -- specialmente il PIN dell'amministratore e il codice di reset
472 (che vi permetterà di azzerare completamente la smartcard). Il PIN
473 dell'amministratore viene usato così raramente che è inevitabile dimenticarselo
474 se non lo si annota.
475
476 Tornando al nostro menu, potete impostare anche altri valori (come il nome,
477 il sesso, informazioni d'accesso, eccetera), ma non sono necessari e aggiunge
478 altre informazioni sulla carta che potrebbero trapelare in caso di smarrimento.
479
480 .. note::
481
482 A dispetto del nome "PIN", né il PIN utente né quello dell'amministratore
483 devono essere esclusivamente numerici.
484
485 .. warning::
486
487 Alcuni dispositivi richiedono la presenza delle sottochiavi nel dispositivo
488 stesso prima che possiate cambiare la passphare. Verificate la
489 documentazione del produttore.
490
491 Spostare le sottochiavi sulla smartcard
492 ---------------------------------------
493
494 Uscite dal menu (usando "q") e salverete tutte le modifiche. Poi, spostiamo
495 tutte le sottochiavi sulla smartcard. Per la maggior parte delle operazioni
496 vi serviranno sia la passphrase della chiave PGP che il PIN
497 dell'amministratore::
498
499 $ gpg --edit-key [fpr]
500
501 Secret subkeys are available.
502
503 pub ed25519/AAAABBBBCCCCDDDD
504 created: 2022-12-20 expires: 2024-12-19 usage: SC
505 trust: ultimate validity: ultimate
506 ssb cv25519/1111222233334444
507 created: 2022-12-20 expires: never usage: E
508 ssb ed25519/5555666677778888
509 created: 2017-12-07 expires: never usage: S
510 [ultimate] (1). Alice Dev <adev@kernel.org>
511
512 gpg>
513
514 Usando ``--edit-key`` si tornerà alla modalità menu e noterete che
515 la lista delle chiavi è leggermente diversa. Da questo momento in poi,
516 tutti i comandi saranno eseguiti nella modalità menu, come indicato
517 da ``gpg>``.
518
519 Per prima cosa, selezioniamo la chiave che verrà messa sulla carta --
520 potete farlo digitando ``key 1`` (è la prima della lista, la sottochiave
521 **[E]**)::
522
523 gpg> key 1
524
525 Nel'output dovreste vedere ``ssb*`` associato alla chiave **[E]**. Il simbolo
526 ``*`` indica che la chiave è stata "selezionata". Funziona come un
527 interruttore, ovvero se scrivete nuovamente ``key 1``, il simbolo ``*`` sparirà
528 e la chiave non sarà più selezionata.
529
530 Ora, spostiamo la chiave sulla smartcard::
531
532 gpg> keytocard
533 Please select where to store the key:
534 (2) Encryption key
535 Your selection? 2
536
537 Dato che è la nostra chiave **[E]**, ha senso metterla nella sezione criptata.
538 Quando confermerete la selezione, vi verrà chiesta la passphrase della vostra
539 chiave PGP, e poi il PIN dell'amministratore. Se il comando ritorna senza
540 errori, allora la vostra chiave è stata spostata con successo.
541
542 **Importante**: digitate nuovamente ``key 1`` per deselezionare la prima chiave
543 e selezionate la seconda chiave **[S]** con ``key 2``::
544
545 gpg> key 1
546 gpg> key 2
547 gpg> keytocard
548 Please select where to store the key:
549 (1) Signature key
550 (3) Authentication key
551 Your selection? 1
552
553 Potete usare la chiave **[S]** sia per firmare che per autenticare, ma vogliamo
554 che sia nella sezione di firma, quindi scegliete (1). Ancora una volta, se il
555 comando ritorna senza errori, allora l'operazione è avvenuta con successo::
556
557 gpg> q
558 Save changes? (y/N) y
559
560 Salvando le modifiche cancellerete dalla vostra cartella home tutte le chiavi
561 che avete spostato sulla carta (ma questo non è un problema, perché abbiamo
562 fatto delle copie di sicurezza nel caso in cui dovessimo configurare una
563 nuova smartcard).
564
565 Verificare che le chiavi siano state spostate
566 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
567
568 Ora, se doveste usare l'opzione ``--list-secret-keys``, vedrete una
569 sottile differenza nell'output::
570
571 $ gpg --list-secret-keys
572 sec# ed25519 2022-12-20 [SC] [expires: 2024-12-19]
573 000000000000000000000000AAAABBBBCCCCDDDD
574 uid [ultimate] Alice Dev <adev@kernel.org>
575 ssb> cv25519 2022-12-20 [E] [expires: 2024-12-19]
576 ssb> ed25519 2022-12-20 [S]
577
578 Il simbolo ``>`` in ``ssb>`` indica che la sottochiave è disponibile solo
579 nella smartcard. Se tornate nella vostra cartella delle chiavi segrete e
580 guardate al suo contenuto, noterete che i file ``.key`` sono stati sostituiti
581 con degli stub::
582
583 $ cd ~/.gnupg/private-keys-v1.d
584 $ strings *.key | grep 'private-key'
585
586 Per indicare che i file sono solo degli stub e che in realtà il contenuto è
587 sulla smartcard, l'output dovrebbe mostrarvi ``shadowed-private-key``.
588
589 Verificare che la smartcard funzioni
590 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
591
592 Per verificare che la smartcard funzioni come dovuto, potete creare
593 una firma::
594
595 $ echo "Hello world" | gpg --clearsign > /tmp/test.asc
596 $ gpg --verify /tmp/test.asc
597
598 Col primo comando dovrebbe chiedervi il PIN della smartcard, e poi dovrebbe
599 mostrare "Good signature" dopo l'esecuzione di ``gpg --verify``.
600
601 Complimenti, siete riusciti a rendere estremamente difficile il furto della
602 vostra identità digitale di sviluppatore.
603
604 Altre operazioni possibili con GnuPG
605 ------------------------------------
606
607 Segue un breve accenno ad alcune delle operazioni più comuni che dovrete
608 fare con le vostre chiavi PGP.
609
610 Montare il disco con la chiave primaria
611 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
612
613 Vi servirà la vostra chiave principale per tutte le operazioni che seguiranno,
614 per cui per prima cosa dovrete accedere ai vostri backup e dire a GnuPG di
615 usarli::
616
617 $ export GNUPGHOME=/media/disk/foo/gnupg-backup
618 $ gpg --list-secret-keys
619
620 Dovete assicurarvi di vedere ``sec`` e non ``sec#`` nell'output del programma
621 (il simbolo ``#`` significa che la chiave non è disponibile e che state ancora
622 utilizzando la vostra solita cartella di lavoro).
623
624 Estendere la data di scadenza di una chiave
625 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
626
627 La chiave principale ha una data di scadenza di 2 anni dal momento della sua
628 creazione. Questo per motivi di sicurezza e per rendere obsolete le chiavi
629 che, eventualmente, dovessero sparire dai keyserver.
630
631 Per estendere di un anno, dalla data odierna, la scadenza di una vostra chiave,
632 eseguite::
633
634 $ gpg --quick-set-expire [fpr] 1y
635
636 Se per voi è più facile da memorizzare, potete anche utilizzare una data
637 specifica (per esempio, il vostro compleanno o capodanno)::
638
639 $ gpg --quick-set-expire [fpr] 2025-07-01
640
641 Ricordatevi di inviare l'aggiornamento ai keyserver::
642
643 $ gpg --send-key [fpr]
644
645 Aggiornare la vostra cartella di lavoro dopo ogni modifica
646 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
647
648 Dopo aver fatto delle modifiche alle vostre chiavi usando uno spazio a parte,
649 dovreste importarle nella vostra cartella di lavoro abituale::
650
651 $ gpg --export | gpg --homedir ~/.gnupg --import
652 $ unset GNUPGHOME
653
654 Usare gpg-agent con ssh
655 ~~~~~~~~~~~~~~~~~~~~~~~
656
657 Se dovete firmare tag o commit su un sistema remoto, potete ridirezionare il
658 vostro gpg-agent attraverso ssh. Consultate le istruzioni disponibili nella wiki
659 GnuPG:
660
661 - `Agent Forwarding over SSH`_
662
663 Funziona senza troppi intoppi se avete la possibilità di modificare le
664 impostazioni di sshd sul sistema remoto.
665
666 .. _`Agent Forwarding over SSH`: https://wiki.gnupg.org/AgentForwarding
667
668 .. _it_pgp_with_git:
669
670 Usare PGP con Git
671 =================
672
673 Una delle caratteristiche fondanti di Git è la sua natura decentralizzata --
674 una volta che il repositorio è stato clonato sul vostro sistema, avete la
675 storia completa del progetto, inclusi i suoi tag, i commit ed i rami. Tuttavia,
676 con i centinaia di repositori clonati che ci sono in giro, come si fa a
677 verificare che la loro copia di linux.git non è stata manomessa da qualcuno?
678
679 Oppure, cosa succede se viene scoperta una backdoor nel codice e la riga
680 "Autore" dice che sei stato tu, mentre tu sei abbastanza sicuro di
681 `non averci niente a che fare`_?
682
683 Per risolvere entrambi i problemi, Git ha introdotto l'integrazione con PGP.
684 I tag firmati dimostrano che il repositorio è integro assicurando che il suo
685 contenuto è lo stesso che si trova sulle macchine degli sviluppatori che hanno
686 creato il tag; mentre i commit firmati rendono praticamente impossibile
687 ad un malintenzionato di impersonarvi senza avere accesso alle vostre chiavi
688 PGP.
689
690 .. _`non averci niente a che fare`: https://github.com/jayphelps/git-blame-someone-else
691
692 Configurare git per usare la vostra chiave PGP
693 ----------------------------------------------
694
695 Se avete solo una chiave segreta nel vostro portachiavi, allora non avete nulla
696 da fare in più dato che sarà la vostra chiave di base. Tuttavia, se doveste
697 avere più chiavi segrete, potete dire a git quale dovrebbe usare (``[fpg]``
698 è la vostra impronta digitale)::
699
700 $ git config --global user.signingKey [fpr]
701
702 Come firmare i tag
703 ------------------
704
705 Per creare un tag firmato, passate l'opzione ``-s`` al comando tag::
706
707 $ git tag -s [tagname]
708
709 La nostra raccomandazione è quella di firmare sempre i tag git, perché
710 questo permette agli altri sviluppatori di verificare che il repositorio
711 git dal quale stanno prendendo il codice non è stato alterato intenzionalmente.
712
713 Come verificare i tag firmati
714 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
715
716 Per verificare un tag firmato, potete usare il comando ``verify-tag``::
717
718 $ git verify-tag [tagname]
719
720 Se state prendendo un tag da un fork del repositorio del progetto, git
721 dovrebbe verificare automaticamente la firma di quello che state prendendo
722 e vi mostrerà il risultato durante l'operazione di merge::
723
724 $ git pull [url] tags/sometag
725
726 Il merge conterrà qualcosa di simile::
727
728 Merge tag 'sometag' of [url]
729
730 [Tag message]
731
732 # gpg: Signature made [...]
733 # gpg: Good signature from [...]
734
735 Se state verificando il tag di qualcun altro, allora dovrete importare
736 la loro chiave PGP. Fate riferimento alla sezione ":ref:`it_verify_identities`"
737 che troverete più avanti.
738
739 Configurare git per firmare sempre i tag con annotazione
740 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
741
742 Se state creando un tag con annotazione è molto probabile che vogliate
743 firmarlo. Per imporre a git di firmare sempre un tag con annotazione,
744 dovete impostare la seguente opzione globale::
745
746 $ git config --global tag.forceSignAnnotated true
747
748 Come usare commit firmati
749 -------------------------
750
751 Creare dei commit firmati è facile, ma è molto più difficile utilizzarli
752 nello sviluppo del kernel linux per via del fatto che ci si affida alle
753 liste di discussione e questo modo di procedere non mantiene le firme PGP
754 nei commit. In aggiunta, quando si usa *rebase* nel proprio repositorio
755 locale per allinearsi al kernel anche le proprie firme PGP verranno scartate.
756 Per questo motivo, la maggior parte degli sviluppatori del kernel non si
757 preoccupano troppo di firmare i propri commit ed ignoreranno quelli firmati
758 che si trovano in altri repositori usati per il proprio lavoro.
759
760 Tuttavia, se avete il vostro repositorio di lavoro disponibile al pubblico
761 su un qualche servizio di hosting git (kernel.org, infradead.org, ozlabs.org,
762 o altri), allora la raccomandazione è di firmare tutti i vostri commit
763 anche se gli sviluppatori non ne beneficeranno direttamente.
764
765 Vi raccomandiamo di farlo per i seguenti motivi:
766
767 1. Se dovesse mai esserci la necessità di fare delle analisi forensi o
768 tracciare la provenienza di un codice, anche sorgenti mantenuti
769 esternamente che hanno firme PGP sui commit avranno un certo valore a
770 questo scopo.
771 2. Se dovesse mai capitarvi di clonare il vostro repositorio locale (per
772 esempio dopo un danneggiamento del disco), la firma vi permetterà di
773 verificare l'integrità del repositorio prima di riprendere il lavoro.
774 3. Se qualcuno volesse usare *cherry-pick* sui vostri commit, allora la firma
775 permetterà di verificare l'integrità dei commit prima di applicarli.
776
777 Creare commit firmati
778 ~~~~~~~~~~~~~~~~~~~~~
779
780 Per creare un commit firmato, dovete solamente aggiungere l'opzione ``-S``
781 al comando ``git commit`` (si usa la lettera maiuscola per evitare
782 conflitti con un'altra opzione)::
783
784 $ git commit -S
785
786 Configurare git per firmare sempre i commit
787 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
788
789 Potete dire a git di firmare sempre i commit::
790
791 git config --global commit.gpgSign true
792
793 .. note::
794
795 Assicuratevi di aver configurato ``gpg-agent`` prima di abilitare
796 questa opzione.
797
798 .. _it_verify_identities:
799
800 Come lavorare con patch firmate
801 -------------------------------
802
803 Esiste la possibilità di usare la vostra chiave PGP per firmare le patch che
804 invierete alla liste di discussione del kernel. I meccanismi esistenti per la
805 firma delle email (PGP-Mime o PGP-inline) tendono a causare problemi
806 nell'attività di revisione del codice. Si suggerisce, invece, di utilizare lo
807 strumento sviluppato da kernel.org che mette nell'intestazione del messaggio
808 un'attestazione delle firme crittografiche (tipo DKIM):
809
810 - `Patatt Patch Attestation`_
811
812 .. _`Patatt Patch Attestation`: https://pypi.org/project/patatt/
813
814 Installare e configurate patatt
815 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
816
817 Lo strumento patatt è disponibile per diverse distribuzioni, dunque cercatelo
818 prima lì. Oppure potete installarlo usano pypi "``pip install patatt``"
819
820 Se avete già configurato git con la vostra chiave PGP (usando
821 ``user.signingKey``), allora patatt non ha bisogno di alcuna configurazione
822 aggiuntiva. Potete iniziare a firmare le vostre patch aggiungendo un aggancio a
823 git-send-email nel vostro repositorio::
824
825 patatt install-hook
826
827 Ora, qualsiasi patch che invierete con ``git send-email`` verrà automaticamente
828 firmata usando la vostra firma crittografica.
829
830 Verificare le firme di patatt
831 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
832
833 Se usate ``b4`` per verificare ed applicare le patch, allora tenterà
834 automaticamente di verificare tutte le firme DKIM e patatt disponibili. Per
835 esempio::
836
837 $ b4 am 20220720205013.890942-1-broonie@kernel.org
838 [...]
839 Checking attestation on all messages, may take a moment...
840 ---
841 ✓ [PATCH v1 1/3] kselftest/arm64: Correct buffer allocation for SVE Z registers
842 ✓ [PATCH v1 2/3] arm64/sve: Document our actual ABI for clearing registers on syscall
843 ✓ [PATCH v1 3/3] kselftest/arm64: Enforce actual ABI for SVE syscalls
844 ---
845 ✓ Signed: openpgp/broonie@kernel.org
846 ✓ Signed: DKIM/kernel.org
847
848 .. note::
849
850 Lo sviluppo di patatt e b4 è piuttosto attivo. Si consiglia di verificare la
851 documentazione più recente.
852
853 .. _it_kernel_identities:
854
855 Come verificare l'identità degli sviluppatori del kernel
856 ========================================================
857
858 Firmare i tag e i commit è facile, ma come si fa a verificare che la chiave
859 usata per firmare qualcosa appartenga davvero allo sviluppatore e non ad un
860 impostore?
861
862 Configurare l'auto-key-retrieval usando WKD e DANE
863 --------------------------------------------------
864
865 Se non siete ancora in possesso di una vasta collezione di chiavi pubbliche
866 di altri sviluppatori, allora potreste iniziare il vostro portachiavi
867 affidandovi ai servizi di auto-scoperta e auto-recupero. GnuPG può affidarsi
868 ad altre tecnologie di delega della fiducia, come DNSSEC e TLS, per sostenervi
869 nel caso in cui iniziare una propria rete di fiducia da zero sia troppo
870 scoraggiante.
871
872 Aggiungete il seguente testo al vostro file ``~/.gnupg/gpg.conf``::
873
874 auto-key-locate wkd,dane,local
875 auto-key-retrieve
876
877 La *DNS-Based Authentication of Named Entities* ("DANE") è un metodo
878 per la pubblicazione di chiavi pubbliche su DNS e per renderle sicure usando
879 zone firmate con DNSSEC. Il *Web Key Directory* ("WKD") è un metodo
880 alternativo che usa https a scopo di ricerca. Quando si usano DANE o WKD
881 per la ricerca di chiavi pubbliche, GnuPG validerà i certificati DNSSEC o TLS
882 prima di aggiungere al vostro portachiavi locale le eventuali chiavi trovate.
883
884 Kernel.org pubblica la WKD per tutti gli sviluppatori che hanno un account
885 kernel.org. Una volta che avete applicato le modifiche al file ``gpg.conf``,
886 potrete auto-recuperare le chiavi di Linus Torvalds e Greg Kroah-Hartman
887 (se non le avete già)::
888
889 $ gpg --locate-keys torvalds@kernel.org gregkh@kernel.org
890
891 Se avete un account kernel.org, al fine di rendere più utile l'uso di WKD
892 da parte di altri sviluppatori del kernel, dovreste `aggiungere alla vostra
893 chiave lo UID di kernel.org`_.
894
895 .. _`aggiungere alla vostra chiave lo UID di kernel.org`: https://korg.wiki.kernel.org/userdoc/mail#adding_a_kernelorg_uid_to_your_pgp_key
896
897 Web of Trust (WOT) o Trust on First Use (TOFU)
898 ----------------------------------------------
899
900 PGP incorpora un meccanismo di delega della fiducia conosciuto come
901 "Web of Trust". Di base, questo è un tentativo di sostituire la necessità
902 di un'autorità certificativa centralizzata tipica del mondo HTTPS/TLS.
903 Invece di avere svariati produttori software che decidono chi dovrebbero
904 essere le entità di certificazione di cui dovreste fidarvi, PGP lascia
905 la responsabilità ad ogni singolo utente.
906
907 Sfortunatamente, solo poche persone capiscono come funziona la rete di fiducia.
908 Nonostante sia un importante aspetto della specifica OpenPGP, recentemente
909 le versioni di GnuPG (2.2 e successive) hanno implementato un meccanisco
910 alternativo chiamato "Trust on First Use" (TOFU). Potete pensare a TOFU come
911 "ad un approccio all fidicia simile ad SSH". In SSH, la prima volta che vi
912 connettete ad un sistema remoto, l'impronta digitale della chiave viene
913 registrata e ricordata. Se la chiave dovesse cambiare in futuro, il programma
914 SSH vi avviserà e si rifiuterà di connettersi, obbligandovi a prendere una
915 decisione circa la fiducia che riponete nella nuova chiave. In modo simile,
916 la prima volta che importate la chiave PGP di qualcuno, si assume sia valida.
917 Se ad un certo punto GnuPG trova un'altra chiave con la stessa identità,
918 entrambe, la vecchia e la nuova, verranno segnate come invalide e dovrete
919 verificare manualmente quale tenere.
920
921 Vi raccomandiamo di usare il meccanisco TOFU+PGP (che è la nuova configurazione
922 di base di GnuPG v2). Per farlo, aggiungete (o modificate) l'impostazione
923 ``trust-model`` in ``~/.gnupg/gpg.conf``::
924
925 trust-model tofu+pgp
926
927 Usare il repositorio kernel.org per il web of trust
928 ---------------------------------------------------
929
930 Il progetto kernel.org mantiene un repositorio git con le chiavi pubbliche degli sviluppatori in alternativa alla replica dei server di chiavi che negli ultimi anni sono spariti. La documentazione completa su come impostare il repositorio come vostra sorgente di chiavi pubbliche può essere trovato qui:
931
932 - `Kernel developer PGP Keyring`_
933
934 Se siete uno sviluppatore del kernel, per favore valutate l'idea di inviare la
935 vostra chiave per l'inclusione in quel portachiavi.
936
937
938 If you are a kernel developer, please consider submitting your key for
939 inclusion into that keyring.
940
941 .. _`Kernel developer PGP Keyring`: https://korg.docs.kernel.org/pgpkeys.html
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.