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