maintainer-pgp-guide.rst (41041B)
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