| .. include:: ../disclaimer-ita.rst |
| |
| :Original: :ref:`Documentation/process/maintainer-pgp-guide.rst <pgpguide>` |
| :Translator: Alessia Mantegazza <amantegazza@vaga.pv.it> |
| |
| .. _it_pgpguide: |
| |
| ========================================= |
| La guida a PGP per manutentori del kernel |
| ========================================= |
| |
| :Author: Konstantin Ryabitsev <konstantin@linuxfoundation.org> |
| |
| Questo documento è destinato agli sviluppatori del kernel Linux, in particolar |
| modo ai manutentori. Contiene degli approfondimenti riguardo informazioni che |
| sono state affrontate in maniera più generale nella sezione |
| "`Protecting Code Integrity`_" pubblicata dalla Linux Foundation. |
| Per approfondire alcuni argomenti trattati in questo documento è consigliato |
| leggere il documento sopraindicato |
| |
| .. _`Protecting Code Integrity`: https://github.com/lfit/itpol/blob/master/protecting-code-integrity.md |
| |
| Il ruolo di PGP nello sviluppo del kernel Linux |
| =============================================== |
| |
| PGP aiuta ad assicurare l'integrità del codice prodotto dalla comunità |
| di sviluppo del kernel e, in secondo luogo, stabilisce canali di comunicazione |
| affidabili tra sviluppatori attraverso lo scambio di email firmate con PGP. |
| |
| Il codice sorgente del kernel Linux è disponibile principalmente in due |
| formati: |
| |
| - repositori distribuiti di sorgenti (git) |
| - rilasci periodici di istantanee (archivi tar) |
| |
| Sia i repositori git che gli archivi tar portano le firme PGP degli |
| sviluppatori che hanno creato i rilasci ufficiali del kernel. Queste firme |
| offrono una garanzia crittografica che le versioni scaricabili rese disponibili |
| via kernel.org, o altri portali, siano identiche a quelle che gli sviluppatori |
| hanno sul loro posto di lavoro. A tal scopo: |
| |
| - i repositori git forniscono firme PGP per ogni tag |
| - gli archivi tar hanno firme separate per ogni archivio |
| |
| .. _it_devs_not_infra: |
| |
| Fidatevi degli sviluppatori e non dell'infrastruttura |
| ----------------------------------------------------- |
| |
| Fin dal 2011, quando i sistemi di kernel.org furono compromessi, il principio |
| generale del progetto Kernel Archives è stato quello di assumere che qualsiasi |
| parte dell'infrastruttura possa essere compromessa in ogni momento. Per questa |
| ragione, gli amministratori hanno intrapreso deliberatemene dei passi per |
| enfatizzare che la fiducia debba risiedere sempre negli sviluppatori e mai nel |
| codice che gestisce l'infrastruttura, indipendentemente da quali che siano le |
| pratiche di sicurezza messe in atto. |
| |
| Il principio sopra indicato è la ragione per la quale è necessaria questa |
| guida. Vogliamo essere sicuri che il riporre la fiducia negli sviluppatori |
| non sia fatto semplicemente per incolpare qualcun'altro per future falle di |
| sicurezza. L'obiettivo è quello di fornire una serie di linee guida che gli |
| sviluppatori possano seguire per creare un ambiente di lavoro sicuro e |
| salvaguardare le chiavi PGP usate nello stabilire l'integrità del kernel Linux |
| stesso. |
| |
| .. _it_pgp_tools: |
| |
| Strumenti PGP |
| ============= |
| |
| Usare GnuPG v2 |
| -------------- |
| |
| La vostra distribuzione potrebbe avere già installato GnuPG, dovete solo |
| verificare che stia utilizzando la versione 2.x e non la serie 1.4 -- |
| molte distribuzioni forniscono entrambe, di base il comando ''gpg'' |
| invoca GnuPG v.1. Per controllate usate:: |
| |
| $ gpg --version | head -n1 |
| |
| Se visualizzate ``gpg (GnuPG) 1.4.x``, allora state usando GnuPG v.1. |
| Provate il comando ``gpg2`` (se non lo avete, potreste aver bisogno |
| di installare il pacchetto gnupg2):: |
| |
| $ gpg2 --version | head -n1 |
| |
| Se visualizzate ``gpg (GnuPG) 2.x.x``, allora siete pronti a partire. |
| Questa guida assume che abbiate la versione 2.2.(o successiva) di GnuPG. |
| Se state usando la versione 2.0, alcuni dei comandi indicati qui non |
| funzioneranno, in questo caso considerate un aggiornamento all'ultima versione, |
| la 2.2. Versioni di gnupg-2.1.11 e successive dovrebbero essere compatibili |
| per gli obiettivi di questa guida. |
| |
| Se avete entrambi i comandi: ``gpg`` e ``gpg2``, assicuratevi di utilizzare |
| sempre la versione V2, e non quella vecchia. Per evitare errori potreste creare |
| un alias:: |
| |
| $ alias gpg=gpg2 |
| |
| Potete mettere questa opzione nel vostro ``.bashrc`` in modo da essere sicuri. |
| |
| Configurare le opzioni di gpg-agent |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| L'agente GnuPG è uno strumento di aiuto che partirà automaticamente ogni volta |
| che userete il comando ``gpg`` e funzionerà in background con l'obiettivo di |
| individuare la passphrase. Ci sono due opzioni che dovreste conoscere |
| per personalizzare la scadenza della passphrase nella cache: |
| |
| - ``default-cache-ttl`` (secondi): Se usate ancora la stessa chiave prima |
| che il time-to-live termini, il conto alla rovescia si resetterà per un |
| altro periodo. Di base è di 600 (10 minuti). |
| |
| - ``max-cache-ttl`` (secondi): indipendentemente da quanto sia recente l'ultimo |
| uso della chiave da quando avete inserito la passphrase, se il massimo |
| time-to-live è scaduto, dovrete reinserire nuovamente la passphrase. |
| Di base è di 30 minuti. |
| |
| Se ritenete entrambe questi valori di base troppo corti (o troppo lunghi), |
| potete creare il vostro file ``~/.gnupg/gpg-agent.conf`` ed impostare i vostri |
| valori:: |
| |
| # set to 30 minutes for regular ttl, and 2 hours for max ttl |
| default-cache-ttl 1800 |
| max-cache-ttl 7200 |
| |
| .. note:: |
| |
| Non è più necessario far partire l'agente gpg manualmente all'inizio della |
| vostra sessione. Dovreste controllare i file rc per rimuovere tutto ciò che |
| riguarda vecchie le versioni di GnuPG, poiché potrebbero non svolgere più |
| bene il loro compito. |
| |
| Impostare un *refresh* con cronjob |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| Potreste aver bisogno di rinfrescare regolarmente il vostro portachiavi in |
| modo aggiornare le chiavi pubbliche di altre persone, lavoro che è svolto |
| al meglio con un cronjob giornaliero:: |
| |
| @daily /usr/bin/gpg2 --refresh >/dev/null 2>&1 |
| |
| Controllate il percorso assoluto del vostro comando ``gpg`` o ``gpg2`` e usate |
| il comando ``gpg2`` se per voi ``gpg`` corrisponde alla versione GnuPG v.1. |
| |
| .. _it_master_key: |
| |
| Proteggere la vostra chiave PGP primaria |
| ======================================== |
| |
| Questa guida parte dal presupposto che abbiate già una chiave PGP che usate |
| per lo sviluppo del kernel Linux. Se non ne avete ancora una, date uno sguardo |
| al documento "`Protecting Code Integrity`_" che abbiamo menzionato prima. |
| |
| Dovreste inoltre creare una nuova chiave se quella attuale è inferiore a 2048 |
| bit (RSA). |
| |
| Chiave principale o sottochiavi |
| ------------------------------- |
| |
| Le sottochiavi sono chiavi PGP totalmente indipendenti, e sono collegate alla |
| chiave principale attraverso firme certificate. È quindi importante |
| comprendere i seguenti punti: |
| |
| 1. Non ci sono differenze tecniche tra la chiave principale e la sottochiave. |
| 2. In fase di creazione, assegniamo limitazioni funzionali ad ogni chiave |
| assegnando capacità specifiche. |
| 3. Una chiave PGP può avere 4 capacità: |
| |
| - **[S]** può essere usata per firmare |
| - **[E]** può essere usata per criptare |
| - **[A]** può essere usata per autenticare |
| - **[C]** può essere usata per certificare altre chiavi |
| |
| 4. Una singola chiave può avere più capacità |
| 5. Una sottochiave è completamente indipendente dalla chiave principale. |
| Un messaggio criptato con la sottochiave non può essere decrittato con |
| quella principale. Se perdete la vostra sottochiave privata, non può |
| essere rigenerata in nessun modo da quella principale. |
| |
| La chiave con capacità **[C]** (certify) è identificata come la chiave |
| principale perché è l'unica che può essere usata per indicare la relazione |
| con altre chiavi. Solo la chiave **[C]** può essere usata per: |
| |
| - Aggiungere o revocare altre chiavi (sottochiavi) che hanno capacità S/E/A |
| - Aggiungere, modificare o eliminare le identità (unids) associate alla chiave |
| - Aggiungere o modificare la data di termine di sé stessa o di ogni sottochiave |
| - Firmare le chiavi di altre persone a scopo di creare una rete di fiducia |
| |
| Di base, alla creazione di nuove chiavi, GnuPG genera quanto segue: |
| |
| - Una chiave madre che porta sia la capacità di certificazione che quella |
| di firma (**[SC]**) |
| - Una sottochiave separata con capacità di criptaggio (**[E]**) |
| |
| Se avete usato i parametri di base per generare la vostra chiave, quello |
| sarà il risultato. Potete verificarlo utilizzando ``gpg --list-secret-keys``, |
| per esempio:: |
| |
| sec rsa2048 2018-01-23 [SC] [expires: 2020-01-23] |
| 000000000000000000000000AAAABBBBCCCCDDDD |
| uid [ultimate] Alice Dev <adev@kernel.org> |
| ssb rsa2048 2018-01-23 [E] [expires: 2020-01-23] |
| |
| Qualsiasi chiave che abbia la capacità **[C]** è la vostra chiave madre, |
| indipendentemente da quali altre capacità potreste averle assegnato. |
| |
| La lunga riga sotto la voce ``sec`` è la vostra impronta digitale -- |
| negli esempi che seguono, quando vedere ``[fpr]`` ci si riferisce a questa |
| stringa di 40 caratteri. |
| |
| Assicuratevi che la vostra passphrase sia forte |
| ----------------------------------------------- |
| |
| GnuPG utilizza le passphrases per criptare la vostra chiave privata prima |
| di salvarla sul disco. In questo modo, anche se il contenuto della vostra |
| cartella ``.gnupg`` venisse letto o trafugato nella sia interezza, gli |
| attaccanti non potrebbero comunque utilizzare le vostre chiavi private senza |
| aver prima ottenuto la passphrase per decriptarle. |
| |
| È assolutamente essenziale che le vostre chiavi private siano protette da |
| una passphrase forte. Per impostarla o cambiarla, usate:: |
| |
| $ gpg --change-passphrase [fpr] |
| |
| Create una sottochiave di firma separata |
| ---------------------------------------- |
| |
| Il nostro obiettivo è di proteggere la chiave primaria spostandola su un |
| dispositivo sconnesso dalla rete, dunque se avete solo una chiave combinata |
| **[SC]** allora dovreste creare una sottochiave di firma separata:: |
| |
| $ gpg --quick-add-key [fpr] ed25519 sign |
| |
| Ricordate di informare il keyserver del vostro cambiamento, cosicché altri |
| possano ricevere la vostra nuova sottochiave:: |
| |
| $ gpg --send-key [fpr] |
| |
| .. note:: Supporto ECC in GnuPG |
| GnuPG 2.1 e successivi supportano pienamente *Elliptic Curve Cryptography*, |
| con la possibilità di combinare sottochiavi ECC con le tradizionali chiavi |
| primarie RSA. Il principale vantaggio della crittografia ECC è che è molto |
| più veloce da calcolare e crea firme più piccole se confrontate byte per |
| byte con le chiavi RSA a più di 2048 bit. A meno che non pensiate di |
| utilizzare un dispositivo smartcard che non supporta le operazioni ECC, vi |
| raccomandiamo ti creare sottochiavi di firma ECC per il vostro lavoro col |
| kernel. |
| |
| Se per qualche ragione preferite rimanere con sottochiavi RSA, nel comando |
| precedente, sostituite "ed25519" con "rsa2048". In aggiunta, se avete |
| intenzione di usare un dispositivo hardware che non supporta le chiavi |
| ED25519 ECC, come la Nitrokey Pro o la Yubikey, allora dovreste usare |
| "nistp256" al posto di "ed25519". |
| |
| Copia di riserva della chiave primaria per gestire il recupero da disastro |
| -------------------------------------------------------------------------- |
| |
| Maggiori sono le firme di altri sviluppatori che vengono applicate alla vostra, |
| maggiori saranno i motivi per avere una copia di riserva che non sia digitale, |
| al fine di effettuare un recupero da disastro. |
| |
| Il modo migliore per creare una copia fisica della vostra chiave privata è |
| l'uso del programma ``paperkey``. Consultate ``man paperkey`` per maggiori |
| dettagli sul formato dell'output ed i suoi punti di forza rispetto ad altre |
| soluzioni. Paperkey dovrebbe essere già pacchettizzato per la maggior parte |
| delle distribuzioni. |
| |
| Eseguite il seguente comando per creare una copia fisica di riserva della |
| vostra chiave privata:: |
| |
| $ gpg --export-secret-key [fpr] | paperkey -o /tmp/key-backup.txt |
| |
| Stampate il file (o fate un pipe direttamente verso lpr), poi prendete |
| una penna e scrivete la passphare sul margine del foglio. **Questo è |
| caldamente consigliato** perché la copia cartacea è comunque criptata con |
| la passphrase, e se mai doveste cambiarla non vi ricorderete qual'era al |
| momento della creazione di quella copia -- *garantito*. |
| |
| Mettete la copia cartacea e la passphrase scritta a mano in una busta e |
| mettetela in un posto sicuro e ben protetto, preferibilmente fuori casa, |
| magari in una cassetta di sicurezza in banca. |
| |
| .. note:: |
| |
| Probabilmente la vostra stampante non è più quello stupido dispositivo |
| connesso alla porta parallela, ma dato che il suo output è comunque |
| criptato con la passphrase, eseguire la stampa in un sistema "cloud" |
| moderno dovrebbe essere comunque relativamente sicuro. |
| |
| Copia di riserva di tutta la cartella GnuPG |
| ------------------------------------------- |
| |
| .. warning:: |
| |
| **!!!Non saltate questo passo!!!** |
| |
| Quando avete bisogno di recuperare le vostre chiavi PGP è importante avere |
| una copia di riserva pronta all'uso. Questo sta su un diverso piano di |
| prontezza rispetto al recupero da disastro che abbiamo risolto con |
| ``paperkey``. Vi affiderete a queste copie esterne quando dovreste usare la |
| vostra chiave Certify -- ovvero quando fate modifiche alle vostre chiavi o |
| firmate le chiavi di altre persone ad una conferenza o ad un gruppo d'incontro. |
| |
| Incominciate con una piccola chiavetta di memoria USB (preferibilmente due) |
| che userete per le copie di riserva. Dovrete criptarle usando LUKS -- fate |
| riferimento alla documentazione della vostra distribuzione per capire come |
| fare. |
| |
| Per la passphrase di criptazione, potete usare la stessa della vostra chiave |
| primaria. |
| |
| Una volta che il processo di criptazione è finito, reinserite il disco USB ed |
| assicurativi che venga montato correttamente. Copiate interamente la cartella |
| ``.gnugp`` nel disco criptato:: |
| |
| $ cp -a ~/.gnupg /media/disk/foo/gnupg-backup |
| |
| Ora dovreste verificare che tutto continui a funzionare:: |
| |
| $ gpg --homedir=/media/disk/foo/gnupg-backup --list-key [fpr] |
| |
| Se non vedete errori, allora dovreste avere fatto tutto con successo. |
| Smontate il disco USB, etichettatelo per bene di modo da evitare di |
| distruggerne il contenuto non appena vi serve una chiavetta USB a caso, ed |
| infine mettetelo in un posto sicuro -- ma non troppo lontano, perché vi servirà |
| di tanto in tanto per modificare le identità, aggiungere o revocare |
| sottochiavi, o firmare le chiavi di altre persone. |
| |
| Togliete la chiave primaria dalla vostra home |
| --------------------------------------------- |
| |
| I file che si trovano nella vostra cartella home non sono poi così ben protetti |
| come potreste pensare. Potrebbero essere letti o trafugati in diversi modi: |
| |
| - accidentalmente quando fate una rapida copia della cartella home per |
| configurare una nuova postazione |
| - da un amministratore di sistema negligente o malintenzionato |
| - attraverso copie di riserva insicure |
| - attraverso malware installato in alcune applicazioni (browser, lettori PDF, |
| eccetera) |
| - attraverso coercizione quando attraversate confini internazionali |
| |
| Proteggere la vostra chiave con una buona passphare aiuta notevolmente a |
| ridurre i rischi elencati qui sopra, ma le passphrase possono essere scoperte |
| attraverso i keylogger, il shoulder-surfing, o altri modi. Per questi motivi, |
| nella configurazione si raccomanda di rimuove la chiave primaria dalla vostra |
| cartella home e la si archivia su un dispositivo disconnesso. |
| |
| .. warning:: |
| |
| Per favore, fate riferimento alla sezione precedente e assicuratevi |
| di aver fatto una copia di riserva totale della cartella GnuPG. Quello |
| che stiamo per fare renderà la vostra chiave inutile se non avete delle |
| copie di riserva utilizzabili! |
| |
| Per prima cosa, identificate il keygrip della vostra chiave primaria:: |
| |
| $ gpg --with-keygrip --list-key [fpr] |
| |
| L'output assomiglierà a questo:: |
| |
| pub rsa2048 2018-01-24 [SC] [expires: 2020-01-24] |
| 000000000000000000000000AAAABBBBCCCCDDDD |
| Keygrip = 1111000000000000000000000000000000000000 |
| uid [ultimate] Alice Dev <adev@kernel.org> |
| sub rsa2048 2018-01-24 [E] [expires: 2020-01-24] |
| Keygrip = 2222000000000000000000000000000000000000 |
| sub ed25519 2018-01-24 [S] |
| Keygrip = 3333000000000000000000000000000000000000 |
| |
| Trovate la voce keygrid che si trova sotto alla riga ``pub`` (appena sotto |
| all'impronta digitale della chiave primaria). Questo corrisponderà direttamente |
| ad un file nella cartella ``~/.gnupg``:: |
| |
| $ cd ~/.gnupg/private-keys-v1.d |
| $ ls |
| 1111000000000000000000000000000000000000.key |
| 2222000000000000000000000000000000000000.key |
| 3333000000000000000000000000000000000000.key |
| |
| Quello che dovrete fare è rimuovere il file .key che corrisponde al keygrip |
| della chiave primaria:: |
| |
| $ cd ~/.gnupg/private-keys-v1.d |
| $ rm 1111000000000000000000000000000000000000.key |
| |
| Ora, se eseguite il comando ``--list-secret-keys``, vedrete che la chiave |
| primaria non compare più (il simbolo ``#`` indica che non è disponibile):: |
| |
| $ gpg --list-secret-keys |
| sec# rsa2048 2018-01-24 [SC] [expires: 2020-01-24] |
| 000000000000000000000000AAAABBBBCCCCDDDD |
| uid [ultimate] Alice Dev <adev@kernel.org> |
| ssb rsa2048 2018-01-24 [E] [expires: 2020-01-24] |
| ssb ed25519 2018-01-24 [S] |
| |
| Dovreste rimuovere anche i file ``secring.gpg`` che si trovano nella cartella |
| ``~/.gnupg``, in quanto rimasugli delle versioni precedenti di GnuPG. |
| |
| Se non avete la cartella "private-keys-v1.d" |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| Se non avete la cartella ``~/.gnupg/private-keys-v1.d``, allora le vostre |
| chiavi segrete sono ancora salvate nel vecchio file ``secring.gpg`` usato |
| da GnuPG v1. Effettuare una qualsiasi modifica alla vostra chiave, come |
| cambiare la passphare o aggiungere una sottochiave, dovrebbe convertire |
| automaticamente il vecchio formato ``secring.gpg``nel nuovo |
| ``private-keys-v1.d``. |
| |
| Una volta che l'avete fatto, assicuratevi di rimuovere il file ``secring.gpg``, |
| che continua a contenere la vostra chiave privata. |
| |
| .. _it_smartcards: |
| |
| Spostare le sottochiavi in un apposito dispositivo criptato |
| =========================================================== |
| |
| Nonostante la chiave primaria sia ora al riparo da occhi e mani indiscrete, |
| le sottochiavi si trovano ancora nella vostra cartella home. Chiunque riesca |
| a mettere le sue mani su quelle chiavi riuscirà a decriptare le vostre |
| comunicazioni o a falsificare le vostre firme (se conoscono la passphrase). |
| Inoltre, ogni volta che viene fatta un'operazione con GnuPG, le chiavi vengono |
| caricate nella memoria di sistema e potrebbero essere rubate con l'uso di |
| malware sofisticati (pensate a Meltdown e a Spectre). |
| |
| Il miglior modo per proteggere le proprie chiave è di spostarle su un |
| dispositivo specializzato in grado di effettuare operazioni smartcard. |
| |
| I benefici di una smartcard |
| --------------------------- |
| |
| Una smartcard contiene un chip crittografico che è capace di immagazzinare |
| le chiavi private ed effettuare operazioni crittografiche direttamente sulla |
| carta stessa. Dato che la chiave non lascia mai la smartcard, il sistema |
| operativo usato sul computer non sarà in grado di accedere alle chiavi. |
| Questo è molto diverso dai dischi USB criptati che abbiamo usato allo scopo di |
| avere una copia di riserva sicura -- quando il dispositivo USB è connesso e |
| montato, il sistema operativo potrà accedere al contenuto delle chiavi private. |
| |
| L'uso di un disco USB criptato non può sostituire le funzioni di un dispositivo |
| capace di operazioni di tipo smartcard. |
| |
| Dispositivi smartcard disponibili |
| --------------------------------- |
| |
| A meno che tutti i vostri computer dispongano di lettori smartcard, il modo |
| più semplice è equipaggiarsi di un dispositivo USB specializzato che |
| implementi le funzionalità delle smartcard. Sul mercato ci sono diverse |
| soluzioni disponibili: |
| |
| - `Nitrokey Start`_: è Open hardware e Free Software, è basata sul progetto |
| `GnuK`_ della FSIJ. Questo è uno dei pochi dispositivi a supportare le chiavi |
| ECC ED25519, ma offre meno funzionalità di sicurezza (come la resistenza |
| alla manomissione o alcuni attacchi ad un canale laterale). |
| - `Nitrokey Pro 2`_: è simile alla Nitrokey Start, ma è più resistente alla |
| manomissione e offre più funzionalità di sicurezza. La Pro 2 supporta la |
| crittografia ECC (NISTP). |
| - `Yubikey 5`_: l'hardware e il software sono proprietari, ma è più economica |
| della Nitrokey Pro ed è venduta anche con porta USB-C il che è utile con i |
| computer portatili più recenti. In aggiunta, offre altre funzionalità di |
| sicurezza come FIDO, U2F, e ora supporta anche le chiavi ECC (NISTP) |
| |
| `Su LWN c'è una buona recensione`_ dei modelli elencati qui sopra e altri. |
| La scelta dipenderà dal costo, dalla disponibilità nella vostra area |
| geografica e vostre considerazioni sull'hardware aperto/proprietario. |
| |
| Se volete usare chiavi ECC, la vostra migliore scelta sul mercato è la |
| Nitrokey Start. |
| |
| .. _`Nitrokey Start`: https://shop.nitrokey.com/shop/product/nitrokey-start-6 |
| .. _`Nitrokey Pro 2`: https://shop.nitrokey.com/shop/product/nitrokey-pro-2-3 |
| .. _`Yubikey 5`: https://www.yubico.com/product/yubikey-5-overview/ |
| .. _Gnuk: http://www.fsij.org/doc-gnuk/ |
| .. _`Su LWN c'è una buona recensione`: https://lwn.net/Articles/736231/ |
| |
| Configurare il vostro dispositivo smartcard |
| ------------------------------------------- |
| |
| Il vostro dispositivo smartcard dovrebbe iniziare a funzionare non appena |
| lo collegate ad un qualsiasi computer Linux moderno. Potete verificarlo |
| eseguendo:: |
| |
| $ gpg --card-status |
| |
| Se vedete tutti i dettagli della smartcard, allora ci siamo. Sfortunatamente, |
| affrontare tutti i possibili motivi per cui le cose potrebbero non funzionare |
| non è lo scopo di questa guida. Se avete problemi nel far funzionare la carta |
| con GnuPG, cercate aiuto attraverso i soliti canali di supporto. |
| |
| Per configurare la vostra smartcard, dato che non c'è una via facile dalla |
| riga di comando, dovrete usate il menu di GnuPG:: |
| |
| $ gpg --card-edit |
| [...omitted...] |
| gpg/card> admin |
| Admin commands are allowed |
| gpg/card> passwd |
| |
| Dovreste impostare il PIN dell'utente (1), quello dell'amministratore (3) e il |
| codice di reset (4). Assicuratevi di annotare e salvare questi codici in un |
| posto sicuro -- specialmente il PIN dell'amministratore e il codice di reset |
| (che vi permetterà di azzerare completamente la smartcard). Il PIN |
| dell'amministratore viene usato così raramente che è inevitabile dimenticarselo |
| se non lo si annota. |
| |
| Tornando al nostro menu, potete impostare anche altri valori (come il nome, |
| il sesso, informazioni d'accesso, eccetera), ma non sono necessari e aggiunge |
| altre informazioni sulla carta che potrebbero trapelare in caso di smarrimento. |
| |
| .. note:: |
| |
| A dispetto del nome "PIN", né il PIN utente né quello dell'amministratore |
| devono essere esclusivamente numerici. |
| |
| Spostare le sottochiavi sulla smartcard |
| --------------------------------------- |
| |
| Uscite dal menu (usando "q") e salverete tutte le modifiche. Poi, spostiamo |
| tutte le sottochiavi sulla smartcard. Per la maggior parte delle operazioni |
| vi serviranno sia la passphrase della chiave PGP che il PIN |
| dell'amministratore:: |
| |
| $ gpg --edit-key [fpr] |
| |
| Secret subkeys are available. |
| |
| pub rsa2048/AAAABBBBCCCCDDDD |
| created: 2018-01-23 expires: 2020-01-23 usage: SC |
| trust: ultimate validity: ultimate |
| ssb rsa2048/1111222233334444 |
| created: 2018-01-23 expires: never usage: E |
| ssb ed25519/5555666677778888 |
| created: 2017-12-07 expires: never usage: S |
| [ultimate] (1). Alice Dev <adev@kernel.org> |
| |
| gpg> |
| |
| Usando ``--edit-key`` si tornerà alla modalità menu e noterete che |
| la lista delle chiavi è leggermente diversa. Da questo momento in poi, |
| tutti i comandi saranno eseguiti nella modalità menu, come indicato |
| da ``gpg>``. |
| |
| Per prima cosa, selezioniamo la chiave che verrà messa sulla carta -- |
| potete farlo digitando ``key 1`` (è la prima della lista, la sottochiave |
| **[E]**):: |
| |
| gpg> key 1 |
| |
| Nel'output dovreste vedere ``ssb*`` associato alla chiave **[E]**. Il simbolo |
| ``*`` indica che la chiave è stata "selezionata". Funziona come un |
| interruttore, ovvero se scrivete nuovamente ``key 1``, il simbolo ``*`` sparirà |
| e la chiave non sarà più selezionata. |
| |
| Ora, spostiamo la chiave sulla smartcard:: |
| |
| gpg> keytocard |
| Please select where to store the key: |
| (2) Encryption key |
| Your selection? 2 |
| |
| Dato che è la nostra chiave **[E]**, ha senso metterla nella sezione criptata. |
| Quando confermerete la selezione, vi verrà chiesta la passphrase della vostra |
| chiave PGP, e poi il PIN dell'amministratore. Se il comando ritorna senza |
| errori, allora la vostra chiave è stata spostata con successo. |
| |
| **Importante**: digitate nuovamente ``key 1`` per deselezionare la prima chiave |
| e selezionate la seconda chiave **[S]** con ``key 2``:: |
| |
| gpg> key 1 |
| gpg> key 2 |
| gpg> keytocard |
| Please select where to store the key: |
| (1) Signature key |
| (3) Authentication key |
| Your selection? 1 |
| |
| Potete usare la chiave **[S]** sia per firmare che per autenticare, ma vogliamo |
| che sia nella sezione di firma, quindi scegliete (1). Ancora una volta, se il |
| comando ritorna senza errori, allora l'operazione è avvenuta con successo:: |
| |
| gpg> q |
| Save changes? (y/N) y |
| |
| Salvando le modifiche cancellerete dalla vostra cartella home tutte le chiavi |
| che avete spostato sulla carta (ma questo non è un problema, perché abbiamo |
| fatto delle copie di sicurezza nel caso in cui dovessimo configurare una |
| nuova smartcard). |
| |
| Verificare che le chiavi siano state spostate |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| Ora, se doveste usare l'opzione ``--list-secret-keys``, vedrete una |
| sottile differenza nell'output:: |
| |
| $ gpg --list-secret-keys |
| sec# rsa2048 2018-01-24 [SC] [expires: 2020-01-24] |
| 000000000000000000000000AAAABBBBCCCCDDDD |
| uid [ultimate] Alice Dev <adev@kernel.org> |
| ssb> rsa2048 2018-01-24 [E] [expires: 2020-01-24] |
| ssb> ed25519 2018-01-24 [S] |
| |
| Il simbolo ``>`` in ``ssb>`` indica che la sottochiave è disponibile solo |
| nella smartcard. Se tornate nella vostra cartella delle chiavi segrete e |
| guardate al suo contenuto, noterete che i file ``.key`` sono stati sostituiti |
| con degli stub:: |
| |
| $ cd ~/.gnupg/private-keys-v1.d |
| $ strings *.key | grep 'private-key' |
| |
| Per indicare che i file sono solo degli stub e che in realtà il contenuto è |
| sulla smartcard, l'output dovrebbe mostrarvi ``shadowed-private-key``. |
| |
| Verificare che la smartcard funzioni |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| Per verificare che la smartcard funzioni come dovuto, potete creare |
| una firma:: |
| |
| $ echo "Hello world" | gpg --clearsign > /tmp/test.asc |
| $ gpg --verify /tmp/test.asc |
| |
| Col primo comando dovrebbe chiedervi il PIN della smartcard, e poi dovrebbe |
| mostrare "Good signature" dopo l'esecuzione di ``gpg --verify``. |
| |
| Complimenti, siete riusciti a rendere estremamente difficile il furto della |
| vostra identità digitale di sviluppatore. |
| |
| Altre operazioni possibili con GnuPG |
| ------------------------------------ |
| |
| Segue un breve accenno ad alcune delle operazioni più comuni che dovrete |
| fare con le vostre chiavi PGP. |
| |
| Montare il disco con la chiave primaria |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| Vi servirà la vostra chiave principale per tutte le operazioni che seguiranno, |
| per cui per prima cosa dovrete accedere ai vostri backup e dire a GnuPG di |
| usarli:: |
| |
| $ export GNUPGHOME=/media/disk/foo/gnupg-backup |
| $ gpg --list-secret-keys |
| |
| Dovete assicurarvi di vedere ``sec`` e non ``sec#`` nell'output del programma |
| (il simbolo ``#`` significa che la chiave non è disponibile e che state ancora |
| utilizzando la vostra solita cartella di lavoro). |
| |
| Estendere la data di scadenza di una chiave |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| La chiave principale ha una data di scadenza di 2 anni dal momento della sua |
| creazione. Questo per motivi di sicurezza e per rendere obsolete le chiavi |
| che, eventualmente, dovessero sparire dai keyserver. |
| |
| Per estendere di un anno, dalla data odierna, la scadenza di una vostra chiave, |
| eseguite:: |
| |
| $ gpg --quick-set-expire [fpr] 1y |
| |
| Se per voi è più facile da memorizzare, potete anche utilizzare una data |
| specifica (per esempio, il vostro compleanno o capodanno):: |
| |
| $ gpg --quick-set-expire [fpr] 2020-07-01 |
| |
| Ricordatevi di inviare l'aggiornamento ai keyserver:: |
| |
| $ gpg --send-key [fpr] |
| |
| Aggiornare la vostra cartella di lavoro dopo ogni modifica |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| Dopo aver fatto delle modifiche alle vostre chiavi usando uno spazio a parte, |
| dovreste importarle nella vostra cartella di lavoro abituale:: |
| |
| $ gpg --export | gpg --homedir ~/.gnupg --import |
| $ unset GNUPGHOME |
| |
| |
| Usare PGP con Git |
| ================= |
| |
| Una delle caratteristiche fondanti di Git è la sua natura decentralizzata -- |
| una volta che il repositorio è stato clonato sul vostro sistema, avete la |
| storia completa del progetto, inclusi i suoi tag, i commit ed i rami. Tuttavia, |
| con i centinaia di repositori clonati che ci sono in giro, come si fa a |
| verificare che la loro copia di linux.git non è stata manomessa da qualcuno? |
| |
| Oppure, cosa succede se viene scoperta una backdoor nel codice e la riga |
| "Autore" dice che sei stato tu, mentre tu sei abbastanza sicuro di |
| `non averci niente a che fare`_? |
| |
| Per risolvere entrambi i problemi, Git ha introdotto l'integrazione con PGP. |
| I tag firmati dimostrano che il repositorio è integro assicurando che il suo |
| contenuto è lo stesso che si trova sulle macchine degli sviluppatori che hanno |
| creato il tag; mentre i commit firmati rendono praticamente impossibile |
| ad un malintenzionato di impersonarvi senza avere accesso alle vostre chiavi |
| PGP. |
| |
| .. _`non averci niente a che fare`: https://github.com/jayphelps/git-blame-someone-else |
| |
| Configurare git per usare la vostra chiave PGP |
| ---------------------------------------------- |
| |
| Se avete solo una chiave segreta nel vostro portachiavi, allora non avete nulla |
| da fare in più dato che sarà la vostra chiave di base. Tuttavia, se doveste |
| avere più chiavi segrete, potete dire a git quale dovrebbe usare (``[fpg]`` |
| è la vostra impronta digitale):: |
| |
| $ git config --global user.signingKey [fpr] |
| |
| **IMPORTANTE**: se avete una comando dedicato per ``gpg2``, allora dovreste |
| dire a git di usare sempre quello piuttosto che il vecchio comando ``gpg``:: |
| |
| $ git config --global gpg.program gpg2 |
| |
| Come firmare i tag |
| ------------------ |
| |
| Per creare un tag firmato, passate l'opzione ``-s`` al comando tag:: |
| |
| $ git tag -s [tagname] |
| |
| La nostra raccomandazione è quella di firmare sempre i tag git, perché |
| questo permette agli altri sviluppatori di verificare che il repositorio |
| git dal quale stanno prendendo il codice non è stato alterato intenzionalmente. |
| |
| Come verificare i tag firmati |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| Per verificare un tag firmato, potete usare il comando ``verify-tag``:: |
| |
| $ git verify-tag [tagname] |
| |
| Se state prendendo un tag da un fork del repositorio del progetto, git |
| dovrebbe verificare automaticamente la firma di quello che state prendendo |
| e vi mostrerà il risultato durante l'operazione di merge:: |
| |
| $ git pull [url] tags/sometag |
| |
| Il merge conterrà qualcosa di simile:: |
| |
| Merge tag 'sometag' of [url] |
| |
| [Tag message] |
| |
| # gpg: Signature made [...] |
| # gpg: Good signature from [...] |
| |
| Se state verificando il tag di qualcun altro, allora dovrete importare |
| la loro chiave PGP. Fate riferimento alla sezione ":ref:`it_verify_identities`" |
| che troverete più avanti. |
| |
| Configurare git per firmare sempre i tag con annotazione |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| Se state creando un tag con annotazione è molto probabile che vogliate |
| firmarlo. Per imporre a git di firmare sempre un tag con annotazione, |
| dovete impostare la seguente opzione globale:: |
| |
| $ git config --global tag.forceSignAnnotated true |
| |
| Come usare commit firmati |
| ------------------------- |
| |
| Creare dei commit firmati è facile, ma è molto più difficile utilizzarli |
| nello sviluppo del kernel linux per via del fatto che ci si affida alle |
| liste di discussione e questo modo di procedere non mantiene le firme PGP |
| nei commit. In aggiunta, quando si usa *rebase* nel proprio repositorio |
| locale per allinearsi al kernel anche le proprie firme PGP verranno scartate. |
| Per questo motivo, la maggior parte degli sviluppatori del kernel non si |
| preoccupano troppo di firmare i propri commit ed ignoreranno quelli firmati |
| che si trovano in altri repositori usati per il proprio lavoro. |
| |
| Tuttavia, se avete il vostro repositorio di lavoro disponibile al pubblico |
| su un qualche servizio di hosting git (kernel.org, infradead.org, ozlabs.org, |
| o altri), allora la raccomandazione è di firmare tutti i vostri commit |
| anche se gli sviluppatori non ne beneficeranno direttamente. |
| |
| Vi raccomandiamo di farlo per i seguenti motivi: |
| |
| 1. Se dovesse mai esserci la necessità di fare delle analisi forensi o |
| tracciare la provenienza di un codice, anche sorgenti mantenuti |
| esternamente che hanno firme PGP sui commit avranno un certo valore a |
| questo scopo. |
| 2. Se dovesse mai capitarvi di clonare il vostro repositorio locale (per |
| esempio dopo un danneggiamento del disco), la firma vi permetterà di |
| verificare l'integrità del repositorio prima di riprendere il lavoro. |
| 3. Se qualcuno volesse usare *cherry-pick* sui vostri commit, allora la firma |
| permetterà di verificare l'integrità dei commit prima di applicarli. |
| |
| Creare commit firmati |
| ~~~~~~~~~~~~~~~~~~~~~ |
| |
| Per creare un commit firmato, dovete solamente aggiungere l'opzione ``-S`` |
| al comando ``git commit`` (si usa la lettera maiuscola per evitare |
| conflitti con un'altra opzione):: |
| |
| $ git commit -S |
| |
| Configurare git per firmare sempre i commit |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| Potete dire a git di firmare sempre i commit:: |
| |
| git config --global commit.gpgSign true |
| |
| .. note:: |
| |
| Assicuratevi di aver configurato ``gpg-agent`` prima di abilitare |
| questa opzione. |
| |
| .. _it_verify_identities: |
| |
| Come verificare l'identità degli sviluppatori del kernel |
| ======================================================== |
| |
| Firmare i tag e i commit è facile, ma come si fa a verificare che la chiave |
| usata per firmare qualcosa appartenga davvero allo sviluppatore e non ad un |
| impostore? |
| |
| Configurare l'auto-key-retrieval usando WKD e DANE |
| -------------------------------------------------- |
| |
| Se non siete ancora in possesso di una vasta collezione di chiavi pubbliche |
| di altri sviluppatori, allora potreste iniziare il vostro portachiavi |
| affidandovi ai servizi di auto-scoperta e auto-recupero. GnuPG può affidarsi |
| ad altre tecnologie di delega della fiducia, come DNSSEC e TLS, per sostenervi |
| nel caso in cui iniziare una propria rete di fiducia da zero sia troppo |
| scoraggiante. |
| |
| Aggiungete il seguente testo al vostro file ``~/.gnupg/gpg.conf``:: |
| |
| auto-key-locate wkd,dane,local |
| auto-key-retrieve |
| |
| La *DNS-Based Authentication of Named Entities* ("DANE") è un metodo |
| per la pubblicazione di chiavi pubbliche su DNS e per renderle sicure usando |
| zone firmate con DNSSEC. Il *Web Key Directory* ("WKD") è un metodo |
| alternativo che usa https a scopo di ricerca. Quando si usano DANE o WKD |
| per la ricerca di chiavi pubbliche, GnuPG validerà i certificati DNSSEC o TLS |
| prima di aggiungere al vostro portachiavi locale le eventuali chiavi trovate. |
| |
| Kernel.org pubblica la WKD per tutti gli sviluppatori che hanno un account |
| kernel.org. Una volta che avete applicato le modifiche al file ``gpg.conf``, |
| potrete auto-recuperare le chiavi di Linus Torvalds e Greg Kroah-Hartman |
| (se non le avete già):: |
| |
| $ gpg --locate-keys torvalds@kernel.org gregkh@kernel.org |
| |
| Se avete un account kernel.org, al fine di rendere più utile l'uso di WKD |
| da parte di altri sviluppatori del kernel, dovreste `aggiungere alla vostra |
| chiave lo UID di kernel.org`_. |
| |
| .. _`aggiungere alla vostra chiave lo UID di kernel.org`: https://korg.wiki.kernel.org/userdoc/mail#adding_a_kernelorg_uid_to_your_pgp_key |
| |
| Web of Trust (WOT) o Trust on First Use (TOFU) |
| ---------------------------------------------- |
| |
| PGP incorpora un meccanismo di delega della fiducia conosciuto come |
| "Web of Trust". Di base, questo è un tentativo di sostituire la necessità |
| di un'autorità certificativa centralizzata tipica del mondo HTTPS/TLS. |
| Invece di avere svariati produttori software che decidono chi dovrebbero |
| essere le entità di certificazione di cui dovreste fidarvi, PGP lascia |
| la responsabilità ad ogni singolo utente. |
| |
| Sfortunatamente, solo poche persone capiscono come funziona la rete di fiducia. |
| Nonostante sia un importante aspetto della specifica OpenPGP, recentemente |
| le versioni di GnuPG (2.2 e successive) hanno implementato un meccanisco |
| alternativo chiamato "Trust on First Use" (TOFU). Potete pensare a TOFU come |
| "ad un approccio all fidicia simile ad SSH". In SSH, la prima volta che vi |
| connettete ad un sistema remoto, l'impronta digitale della chiave viene |
| registrata e ricordata. Se la chiave dovesse cambiare in futuro, il programma |
| SSH vi avviserà e si rifiuterà di connettersi, obbligandovi a prendere una |
| decisione circa la fiducia che riponete nella nuova chiave. In modo simile, |
| la prima volta che importate la chiave PGP di qualcuno, si assume sia valida. |
| Se ad un certo punto GnuPG trova un'altra chiave con la stessa identità, |
| entrambe, la vecchia e la nuova, verranno segnate come invalide e dovrete |
| verificare manualmente quale tenere. |
| |
| Vi raccomandiamo di usare il meccanisco TOFU+PGP (che è la nuova configurazione |
| di base di GnuPG v2). Per farlo, aggiungete (o modificate) l'impostazione |
| ``trust-model`` in ``~/.gnupg/gpg.conf``:: |
| |
| trust-model tofu+pgp |
| |
| Come usare i keyserver in sicurezza |
| ----------------------------------- |
| Se ottenete l'errore "No public key" quando cercate di validate il tag di |
| qualcuno, allora dovreste cercare quella chiave usando un keyserver. È |
| importante tenere bene a mente che non c'è alcuna garanzia che la chiave |
| che avete recuperato da un keyserver PGP appartenga davvero alla persona |
| reale -- è progettato così. Dovreste usare il Web of Trust per assicurarvi |
| che la chiave sia valida. |
| |
| Come mantenere il Web of Trust va oltre gli scopi di questo documento, |
| semplicemente perché farlo come si deve richiede sia sforzi che perseveranza |
| che tendono ad andare oltre al livello di interesse della maggior parte degli |
| esseri umani. Qui di seguito alcuni rapidi suggerimenti per aiutarvi a ridurre |
| il rischio di importare chiavi maligne. |
| |
| Primo, diciamo che avete provato ad eseguire ``git verify-tag`` ma restituisce |
| un errore dicendo che la chiave non è stata trovata:: |
| |
| $ git verify-tag sunxi-fixes-for-4.15-2 |
| gpg: Signature made Sun 07 Jan 2018 10:51:55 PM EST |
| gpg: using RSA key DA73759BF8619E484E5A3B47389A54219C0F2430 |
| gpg: issuer "wens@...org" |
| gpg: Can't check signature: No public key |
| |
| Cerchiamo nel keyserver per maggiori informazioni sull'impronta digitale |
| della chiave (l'impronta digitale, probabilmente, appartiene ad una |
| sottochiave, dunque non possiamo usarla direttamente senza trovare prima |
| l'ID della chiave primaria associata ad essa):: |
| |
| $ gpg --search DA73759BF8619E484E5A3B47389A54219C0F2430 |
| gpg: data source: hkp://keys.gnupg.net |
| (1) Chen-Yu Tsai <wens@...org> |
| 4096 bit RSA key C94035C21B4F2AEB, created: 2017-03-14, expires: 2019-03-15 |
| Keys 1-1 of 1 for "DA73759BF8619E484E5A3B47389A54219C0F2430". Enter number(s), N)ext, or Q)uit > q |
| |
| Localizzate l'ID della chiave primaria, nel nostro esempio |
| ``C94035C21B4F2AEB``. Ora visualizzate le chiavi di Linus Torvalds |
| che avete nel vostro portachiavi:: |
| |
| $ gpg --list-key torvalds@kernel.org |
| pub rsa2048 2011-09-20 [SC] |
| ABAF11C65A2970B130ABE3C479BE3E4300411886 |
| uid [ unknown] Linus Torvalds <torvalds@kernel.org> |
| sub rsa2048 2011-09-20 [E] |
| |
| Poi, cercate un percorso affidabile da Linux Torvalds alla chiave che avete |
| trovato con ``gpg --search`` usando la chiave sconosciuta.Per farlo potete usare |
| diversi strumenti come https://github.com/mricon/wotmate, |
| https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/tree/graphs, e |
| https://the.earth.li/~noodles/pathfind.html. |
| |
| Se trovate un paio di percorsi affidabili è un buon segno circa la validità |
| della chiave. Ora, potete aggiungerla al vostro portachiavi dal keyserver:: |
| |
| $ gpg --recv-key C94035C21B4F2AEB |
| |
| Questa procedura non è perfetta, e ovviamente state riponendo la vostra |
| fiducia nell'amministratore del servizio *PGP Pathfinder* sperando che non |
| sia malintenzionato (infatti, questo va contro :ref:`it_devs_not_infra`). |
| Tuttavia, se mantenete con cura la vostra rete di fiducia sarà un deciso |
| miglioramento rispetto alla cieca fiducia nei keyserver. |
