Differences between revisions 1 and 17 (spanning 16 versions)
Revision 1 as of 2012-10-08 16:58:53
Size: 10155
Comment: first translated version
Revision 17 as of 2020-12-11 13:46:59
Size: 13107
Comment: sync with English master v.44
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## page was renamed from it/subkeys
Line 2: Line 3:
~-[[DebianWiki/EditorGuide#translation|Translation(s)]] : [[subkeys|English]] -Italiano-~ ~-[[DebianWiki/EditorGuide#translation|Traduzioni]]: [[Subkeys|English]] - [[fr/Subkeys|Français]] - Italiano-~
Line 30: Line 31:
Le sottochiavi rendono tutto ciò più semplice: si crea una sottochiave per firmare e un'altra per la cifratura e le si conserva sul proprio computer principale. Si pubblicano le sottochiavi sui normali server di chiavi e tutti le useranno al posto delle chiavi principali, con una eccezione. In modo analogo l'utente userà le chiavi principali solo in circostanze eccezionali. Le sottochiavi rendono tutto ciò più semplice: si ha già una sottochiave di cifratura creata automaticamente e si crea un'altra sottochiave per firmare e le si conserva sul proprio computer principale. Un utente pubblica le sottochiavi sui normali server di chiavi e tutti le useranno al posto delle chiavi principali per cifrare i messaggi o verificare le sue firme dei messaggi. In modo analogo l'utente userà le sottochiavi per decifrare e firmare i messaggi.
Line 32: Line 33:
Le eccezioni sono: Sarà necessario usare le chiavi principali solamente in circostanze eccezionali, e cioè quando si desidera modificare la propria chiave o quella di qualcun altro. Più specificamente è necessaria la chiave principale privata:
 * quando si firma la chiave di qualcun altro o quando si revoca una firma esistente;
 * quando si aggiunge un nuovo UID o si contrassegna un UID esistente come "primario";
 * quando si crea una nuova sottochiave;
 * quando si revoca un UID o sottochiave esistente;
 * quando si cambiano le preferenze (es. con `setpref`) di un UID;
 * quando si cambia la data di scadenza della chiave principale o di una qualsiasi delle sue sottochiavi, oppure
 * quando si revoca o si genera il certificato di revoca per la chiave completa.
Line 34: Line 42:
 * quando si firma la chiave di qualcun altro; ciò viene fatto usando la chiave privata di firma principale
 * quando è necessario creare una nuova sottochiave, perché per associare la sottochiave alla chiave principale è necessaria una firma della chiave privata principale
 * quando è necessario revocare le sottochiavi; ciò viene fatto usando la chiave privata principale
(Poiché ognuna di queste operazioni viene fatta aggiungendo una nuova firma o firma di revoca dalla chiave privata principale.)
Line 38: Line 44:
Nel caso che la sottochiave venga rubata mentre la chiave principale rimane sicura, si può revocare la sottochiave compromessa e sostituirla con una nuova sottochiave senza dover ricostruire la propria reputazione e senza ridurre la reputazione delle chiavi di altri firmate dalla propria chiave principale. Dato che ogni anello della Rete di fiducia è un avvallo del collegamento tra una chiave pubblica e un ID utente, le firme dei certificati OpenPGP (dalla chiave principale privata del firmatario) sono relative ad un UID e sono irrilevanti per le sottochiavi. In particolare la creazione o revoca di sottochiavi non ha effetto sulla reputazione della chiave principale. Perciò nel caso che la sottochiave venga rubata mentre la chiave principale rimane sicura, si può revocare la sottochiave compromessa e sostituirla con una nuova sottochiave senza dover ricostruire la propria reputazione e senza ridurre la reputazione delle chiavi di altri firmate dalla propria chiave principale.
Line 48: Line 54:
  * `tar -cf $HOME/gnupg-backup.tar -C $HOME .gnupg`
 (notare: questo (per i valori predefiniti controllare umask) crear il file leggibile da tutti $HOME/gnupg-backup.tar con tutto il proprio portachiavi, incluse tutte le chiavi segrete. Il portachiavi originale (la directory .gnupg) ha permessi più restrittivi.)
  * `umask 077; tar -cf $HOME/gnupg-backup.tar -C $HOME .gnupg`
 (notare: l'umask 077 avrà come risultato permessi più restrittivi per il backup.)
Line 60: Line 66:
 1. Si può ripetere il procedimento e creare anche una sottochiave "RSA (solo cifratura)", se lo si desidera. Per Debian è sufficiente solo la chiave per la firma.  1. Si può ripetere il procedimento e creare anche una sottochiave "RSA (solo cifratura)", se lo si desidera o se si deve farlo. Come detto in precedenza, tenere a mente che l'opzione predefinita quando si crea inizialmente un nuovo paio di chiavi è di creare una sottochiave di cifratura, perciò probabilmente se ne ha già una. Ad ogni modo, per Debian è sufficiente solo la chiave per la firma.
Line 62: Line 68:
 1. Ora inizia la parte delicata. È necessario rimuovere la chiave privata principale e GnuPG non fornisce un modo comodo per farlo. È necessario esportare la sottochiave, rimuovere la chiave privata e reimportare la sottochiave.
  * Trovare l'ID della chiave della nuova sottochiave segreta: `gpg --list-secret-keys`
  * Esportarla: `gpg --export-secret-subkey IDSOTTOCHIAVE! > sottochiave`
  * Ripetere il procedimento per ogni altra sottochiave che si desidera mantenere sulla macchina principale (ogni volta salvare in un file diverso).
  * Esportare anche le chiavi pubbliche: `gpg --export IDPROPRIACHIAVEPRINCIPALE > chiavipubbliche`
  * Rimuovere la chiave principale: `gpg --delete-secret-key IDPROPRIACHIAVE`
  * Reimportare: `gpg --import chiavipubbliche sottochiave`
  * Verificare che `gpg -K` mostri `sec#` invece del solo `sec` per la propria chiave privata. Ciò significa che la chiave segreta non è realmente presente.
 1. Ora inizia la parte delicata. È necessario rimuovere la chiave privata principale.
  * Se si sta usando GnuPG 2.1 o successivo, tutto ciò che è necessario fare è cancellare il file `$HOME/.gnupg/private-keys-v1.d/KEYGRIP.key`, dove `KEYGRIP` è il "keygrip" della chiave principale che può essere trovato eseguendo `gpg2 --with-keygrip --list-key IDPROPRIACHIAVEPRINCIPALE`. (La parte privata di ogni coppia di chiavi ha un keygrip, per cui questo comando elenca un keygrip per la chiave principale e uno per ogni sottochiave.) Notare però che se il portachiavi è stato appena migrato al nuovo formato, allora il file `$HOME/.gnupg/secring.gpg` ora obsoleto potrebbe contenere sempre la chiave privata principale: perciò assicurarsi di eliminare anche quel file se non è vuoto.
  * Sfortunatamente GnuPG <2.1 non fornisce un modo comodo per rimuovere la chiave privata principale. È necessario invece esportare la sottochiave, rimuovere la chiave privata e reimportare la sottochiave.
  * Esportare le sottochiavi: `gpg --output sottochiavi-segrete --export-secret-subkeys IDPROPRIACHIAVEPRINCIPALE`. In alternativa, per scegliere quali sottochiavi esportare, specificare gli ID delle sottochiavi seguiti da un punto esclamativo `gpg --output sottochiavi-segrete --export-secret-subkeys IDSOTTOCHIAVE! [IDSOTTOCHIAVE! ..]`
  * Rimuovere la chiave segreta principale: `gpg --delete-secret-keys IDPROPRIACHIAVEPRINCIPALE`
  * Reimportare le sottochiavi: `gpg --import sottochiavi-segrete`
  * Rimuovere il file contenente le sottochiavi private: `rm sottochiavi-segrete`
 Verificare che `gpg -K` mostri `sec#` invece del solo `sec` per la propria chiave privata. Ciò significa che la chiave segreta non è realmente presente. (Vedere anche la presenza di un pacchetto OpenPGP fittizio nell'output di `gpg --export-secret-keys IDPROPRIACHIAVEPRINCIPALE | gpg --list-packets`.)
 1. Cambiare la passphrase che protegge le sottochiavi: `gpg --edit-key IDPROPRIACHIAVEPRINCIPALE password`. In questo modo se la passphrase di tutti i giorni viene compromessa, la chiave master privata rimane al sicuro da qualcuno con accesso al backup: il materiale della chiave privata nel backup, inclusa la chiave principale privata, rimarrà protetto dalla vecchia passphrase.
Line 80: Line 87:
oppure usare nella riga di comando l'opzione --home : oppure usare nella riga di comando l'opzione '--homedir' :
Line 83: Line 90:
gpg --home=/media/qualcosa -K gpg --homedir=/media/qualcosa -K
Line 93: Line 100:
gpg --send-key --keyserver keyring.debian.org IDPROPRIACHIAVEPRINCIPALE
gpg --send-key --keyserver subkeys.pgp.net IDPROPRIACHIAVEPRINCIPALE
gpg --keyserver hkp://keyring.debian.org --send-key IDPROPRIACHIAVEPRINCIPALE
gpg --keyserver hkp://pool.sks-keyservers.net --send-key IDPROPRIACHIAVEPRINCIPALE
Line 98: Line 106:
(Vedere http://anonscm.debian.org/loggerhead/keyring/debian-keyring/changes per sapere se la propria sottochiave è stata aggiunta.) (Vedere https://salsa.debian.org/debian-keyring/keyring/commits/master per sapere se la propria sottochiave è stata aggiunta.)

Perciò ci potrebbe volere 1 mese affinché la nuova sottochiave venga aggiornata nei server Debian online.
Line 104: Line 114:
Fatto questo, si dovrebbe essere in grado di caricare pacchetti in Debian usando la sottochiave, invece della chiave principale.

Se la propria chiave era già presente nel portachiavi di backports, sarà necessario aprire un ticket nel [[https://rt.debian.org/Ticket/Create.html?Queue=20|tracciatore di richieste]] per chiedere che la propria chiave venga aggiornata in modo da poter nuovamente caricare su backports.debian.org.
Fatto questo, si dovrebbe essere in grado di caricare pacchetti in Debian usando la sottochiave, invece della chiave principale. La sottochiave erediterà la rete di fiducia della coppia di chiavi principale.
Line 118: Line 126:

== Avvertimenti ==

=== Più sottochiavi per macchina o un'unica sottochiave per tutte le macchine ===

Si potrebbe essere tentati di avere una sottochiave per ciascuna macchina in modo da dover cambiare solo la sottochiave potenzialmente compromessa di quella macchina. Nel caso di una sottochiave usata su tutte le macchine, in caso di compromissione, essa deve essere cambiata su tutte le macchine.

Ma ciò funziona solo per la firma di sottochiavi. Se si hanno più sottochiavi di cifratura, gpg cifra solo per la più recente sottochiave di cifratura e non per tutte le sottochiavi conosciute e non revocate.

Traduzioni: English - Français - Italiano


Usare sottochiavi OpenPGP nello sviluppo di Debian

Cosa sono le chiavi?

Nella crittografia a chiave pubblica, una chiave è in realtà una coppia: una chiave pubblica e una chiave privata. Si usa la chiave privata per firmare in modo digitale i file e gli altri usano la chiave pubblica per verificare la firma. Oppure gli altri usano la chiave pubblica per cifrare qualcosa e il destinatario usa la chiave privata per decifrarlo.

Fino a che l'utente ha accesso alla propria chiave privata, gli altri possono fare affidamento sulle firme digitali che egli fa, e lui può fare affidamento sul fatto che nessuno altro possa leggere i messaggi cifrati destinati a lui.

GnuPG, l'implementazione usata in Debian, prende la chiave giusta in un dato momento.

Cosa sono le sottochiavi?

OpenPGP gestisce inoltre le sottochiavi, che sono come chiavi normali tranne per il fatto che sono legate ad una coppia di chiavi principali. Una sottochiave può essere usata per firmare o per la cifratura. L'aspetto veramente utile delle sottochiavi è il fatto che possono essere revocate indipendentemente dalle chiavi principali così come possono essere archiviate separatamente.

In altre parole, le sottochiavi sono come un paio di chiavi separate, ma sono automaticamente associate al paio di chiavi principale.

GnuPG di fatto usa una chiave solo per firmare come chiave principale e crea automaticamente una sottochiave di cifratura. Senza una sottochiave per la cifratura, non si possono ottenere affatto messaggi di posta elettronica cifrati con GnuPG. Debian richiede il possesso di una sottochiave di cifratura in modo che certi tipi di dati possano essere inviati in modo sicuro per posta elettronica all'utente, come la password iniziale per l'account shell di debian.org.

Perché

Le sottochiavi rendono più facile la gestione delle chiavi. Il paio di chiavi principale è piuttosto importante: è la migliore prova della propria identità online, almeno per Debian, e se la si perde è necessario ricostruire la propria reputazione partendo da zero. Se qualcun altro ottiene l'accesso alla chiave privata principale dell'utente o alla sua sottochiave privata, può far credere a tutti di essere l'utente: può caricare pacchetti a suo nome, votare a suo nome e fare praticamente qualsiasi altra cosa che può fare l'utente. Questo può essere un grande danno per Debian. Inoltre non è piacevole per l'utente. Perciò si devono mantenere al sicuro tutte le proprie chiavi private.

Si dovrebbe mantenere la propria chiave privata principale molto molto al sicuro. Tuttavia, mantenere tutte le proprie chiavi estremamente al sicuro è scomodo: ogni volta che si deve firmare un nuovo caricamento di pacchetti è necessario copiare i pacchetti su un supporto portabile adatto, andare nello scantinato, dimostrare alle guardie armate la propria identità usando svariati metodi biometrici e altri tipi di identificazione, attraversare un labirinto mortale, dare da mangiare ai cani da guardia il giusto tipo di carne e da ultimo aprire la cassaforte, tirare fuori il portatile per la firma e firmare i pacchetti. Poi fare il percorso inverso per tornare alla propria connessione ad Internet per caricare i pacchetti.

Le sottochiavi rendono tutto ciò più semplice: si ha già una sottochiave di cifratura creata automaticamente e si crea un'altra sottochiave per firmare e le si conserva sul proprio computer principale. Un utente pubblica le sottochiavi sui normali server di chiavi e tutti le useranno al posto delle chiavi principali per cifrare i messaggi o verificare le sue firme dei messaggi. In modo analogo l'utente userà le sottochiavi per decifrare e firmare i messaggi.

Sarà necessario usare le chiavi principali solamente in circostanze eccezionali, e cioè quando si desidera modificare la propria chiave o quella di qualcun altro. Più specificamente è necessaria la chiave principale privata:

  • quando si firma la chiave di qualcun altro o quando si revoca una firma esistente;
  • quando si aggiunge un nuovo UID o si contrassegna un UID esistente come "primario";
  • quando si crea una nuova sottochiave;
  • quando si revoca un UID o sottochiave esistente;
  • quando si cambiano le preferenze (es. con setpref) di un UID;

  • quando si cambia la data di scadenza della chiave principale o di una qualsiasi delle sue sottochiavi, oppure
  • quando si revoca o si genera il certificato di revoca per la chiave completa.

(Poiché ognuna di queste operazioni viene fatta aggiungendo una nuova firma o firma di revoca dalla chiave privata principale.)

Dato che ogni anello della Rete di fiducia è un avvallo del collegamento tra una chiave pubblica e un ID utente, le firme dei certificati OpenPGP (dalla chiave principale privata del firmatario) sono relative ad un UID e sono irrilevanti per le sottochiavi. In particolare la creazione o revoca di sottochiavi non ha effetto sulla reputazione della chiave principale. Perciò nel caso che la sottochiave venga rubata mentre la chiave principale rimane sicura, si può revocare la sottochiave compromessa e sostituirla con una nuova sottochiave senza dover ricostruire la propria reputazione e senza ridurre la reputazione delle chiavi di altri firmate dalla propria chiave principale.

Come?

Sfortunatamente l'interfaccia utente di GnuPG non è proprio un divertimento da usare. Di seguito verranno mostrati i passi necessari uno a uno.

In queste istruzioni si presume l'uso di un computer e che le chiavi principali siano conservate su un'unità USB cifrata o preferibilmente almeno due (si dovrebbero mantenere dei backup delle proprie chiavi segrete). Si presume inoltre che si abbia già una chiave; se ciò non fosse vero, guardare http://keyring.debian.org/creating-key.html per le istruzioni a riguardo.

  1. Fare dei backup dei file GnuPG esistenti ($HOME/.gnupg). Tenerli al sicuro. Se qualcosa va storto durante i passi descritti in seguito, potrebbero essere necessari per ritornare ad una situazione che si sa funzionare.

    • umask 077; tar -cf $HOME/gnupg-backup.tar -C $HOME .gnupg

    (notare: l'umask 077 avrà come risultato permessi più restrittivi per il backup.)
  2. Creare una nuova sottochiave per firmare.
    • Trovare l'ID della propria chiave: gpg --list-keys proprionome

    • gpg --edit-key IDPROPRIACHIAVEPRINCIPALE

    • Al prompt gpg>: addkey

    • Viene chiesta la propria passphrase, digitarla.
    • Scegliere il tipo di chiave "RSA (solo firma)".
    • Sarebbe saggio scegliere una dimensione della chiave di 4096 (o 2048) bit.
    • Scegliere una data di scadenza (si possono ruotare le proprie sottochiavi più frequentemente delle chiavi principali, oppure mantenerle per tutta la durata della chiave principale, senza scadenza).
    • GnuPG creerà (prima o poi) una chiave, ma si deve attendere che raccolga abbastanza entropia per farlo.
    • Salvare la chiave con: save

  3. Si può ripetere il procedimento e creare anche una sottochiave "RSA (solo cifratura)", se lo si desidera o se si deve farlo. Come detto in precedenza, tenere a mente che l'opzione predefinita quando si crea inizialmente un nuovo paio di chiavi è di creare una sottochiave di cifratura, perciò probabilmente se ne ha già una. Ad ogni modo, per Debian è sufficiente solo la chiave per la firma.
  4. Ora copiare $HOME/.gnupg nelle proprie unità USB.

  5. Ora inizia la parte delicata. È necessario rimuovere la chiave privata principale.
    • Se si sta usando GnuPG 2.1 o successivo, tutto ciò che è necessario fare è cancellare il file $HOME/.gnupg/private-keys-v1.d/KEYGRIP.key, dove KEYGRIP è il "keygrip" della chiave principale che può essere trovato eseguendo gpg2 --with-keygrip --list-key IDPROPRIACHIAVEPRINCIPALE. (La parte privata di ogni coppia di chiavi ha un keygrip, per cui questo comando elenca un keygrip per la chiave principale e uno per ogni sottochiave.) Notare però che se il portachiavi è stato appena migrato al nuovo formato, allora il file $HOME/.gnupg/secring.gpg ora obsoleto potrebbe contenere sempre la chiave privata principale: perciò assicurarsi di eliminare anche quel file se non è vuoto.

    • Sfortunatamente GnuPG <2.1 non fornisce un modo comodo per rimuovere la chiave privata principale. È necessario invece esportare la sottochiave, rimuovere la chiave privata e reimportare la sottochiave.

    • Esportare le sottochiavi: gpg --output sottochiavi-segrete --export-secret-subkeys IDPROPRIACHIAVEPRINCIPALE. In alternativa, per scegliere quali sottochiavi esportare, specificare gli ID delle sottochiavi seguiti da un punto esclamativo gpg --output sottochiavi-segrete --export-secret-subkeys IDSOTTOCHIAVE! [IDSOTTOCHIAVE! ..]

    • Rimuovere la chiave segreta principale: gpg --delete-secret-keys IDPROPRIACHIAVEPRINCIPALE

    • Reimportare le sottochiavi: gpg --import sottochiavi-segrete

    • Rimuovere il file contenente le sottochiavi private: rm sottochiavi-segrete

    Verificare che gpg -K mostri sec# invece del solo sec per la propria chiave privata. Ciò significa che la chiave segreta non è realmente presente. (Vedere anche la presenza di un pacchetto OpenPGP fittizio nell'output di gpg --export-secret-keys IDPROPRIACHIAVEPRINCIPALE | gpg --list-packets.)

  6. Cambiare la passphrase che protegge le sottochiavi: gpg --edit-key IDPROPRIACHIAVEPRINCIPALE password. In questo modo se la passphrase di tutti i giorni viene compromessa, la chiave master privata rimane al sicuro da qualcuno con accesso al backup: il materiale della chiave privata nel backup, inclusa la chiave principale privata, rimarrà protetto dalla vecchia passphrase.

Il computer è ora pronto per l'uso normale.

Quando è necessario usare le chiavi principali, montare l'unità USB cifrata e impostare la variabile d'ambiente GNUPGHOME:

export GNUPGHOME=/media/qualcosa
gpg -K

oppure usare nella riga di comando l'opzione '--homedir' :

gpg --homedir=/media/qualcosa -K

Quest'ultimo comando dovrebbe ora mostra la propria chiave privata con sec e non sec#.

E poi?

A questo punto si ha una sottochiave ed è necessario inviarla al server di chiavi di Debian, se la propria chiave è gia nel portachiavi Debian e nella rete generale dei server di chiavi:

gpg --keyserver hkp://keyring.debian.org --send-key IDPROPRIACHIAVEPRINCIPALE
gpg --keyserver hkp://pool.sks-keyservers.net --send-key IDPROPRIACHIAVEPRINCIPALE

Il caricamento sul server di chiavi Debian funziona solo se la chiave principale pubblica è gia nei portachiavi dei DD o DM: il server di chiavi Debian accetta aggiornamenti alle chiavi esistenti, ma non chiavi nove. Le nuove chiavi vengono aggiunte a mano dai manutentori del portachiavi. Gli aggiornamenti alle chiavi necessitano di un ulteriore aggiornamento manuale per poter essere aggiunte al portachiavi effettivamente usato dai server di Debian e questo di solito viene fatto una volta al mese. (Vedere https://salsa.debian.org/debian-keyring/keyring/commits/master per sapere se la propria sottochiave è stata aggiunta.)

Perciò ci potrebbe volere 1 mese affinché la nuova sottochiave venga aggiornata nei server Debian online.

(La prima volta che la propria chiave viene aggiunta ai portachiavi Debian: manualmente, quando si viene accettati come DD o DM. Dopo di ciò, aggiornamento delle sottochiavi nel server di chaivi: automatico. Copia degli aggiornamenti dal server di chiavi ai portachiavi Debian: manuale, una volta al mese.)

Fatto questo, si dovrebbe essere in grado di caricare pacchetti in Debian usando la sottochiave, invece della chiave principale. La sottochiave erediterà la rete di fiducia della coppia di chiavi principale.

Aiuto!

Se succede un disastro ed è necessario revocare la sottochiave per una ragione qualsiasi, fare ciò che segue:

  1. Montare l'unità USB cifrata.
  2. export GNUPGHOME=/media/propriaunita

  3. gpg --edit-key IDPROPRIACHIAVEPRINCIPALE

  4. Al prompt gpg>, elencare le chiavi (list), selezionare quella desiderata (chiave 123) e generare un certificato di revoca (revkey), poi salvare.

  5. Inviare la chiave aggiornata ai server di chiavi come descritto sopra.

Avvertimenti

Più sottochiavi per macchina o un'unica sottochiave per tutte le macchine

Si potrebbe essere tentati di avere una sottochiave per ciascuna macchina in modo da dover cambiare solo la sottochiave potenzialmente compromessa di quella macchina. Nel caso di una sottochiave usata su tutte le macchine, in caso di compromissione, essa deve essere cambiata su tutte le macchine.

Ma ciò funziona solo per la firma di sottochiavi. Se si hanno più sottochiavi di cifratura, gpg cifra solo per la più recente sottochiave di cifratura e non per tutte le sottochiavi conosciute e non revocate.