Come gestire le chiavi GPG su più sistemi?

Sono nuovo nell'uso di GnuPG e nel tentativo di capire come utilizzarlo al meglio. Ho esaminato la spiegazione breve e di facile comprensione di GPG / PGP per persone non tecniche? , ma la maggior parte delle guide spiega PGP con una prospettiva a macchina singola.

Voglio usare GnuPG su tre dispositivi informatici: un PC Linux, un laptop Linux e un telefono Android.

Il caso d'uso fondamentale è la crittografia / decrittografia della posta elettronica gestita da un servizio IMAP, quindi tutti i dispositivi necessitano della stessa chiave privata per la decrittazione.

Immagino che le mie scelte siano:

1. Basta copiare tutte le mie chiavi sul portachiavi su ciascun dispositivo e fare affidamento principalmente sulla password della chiave privata per la protezione.

2. Crea una chiave master (con --gen-key) per rappresentare la mia identità, quindi crea una chiave monouso separata (sempre con --gen-key) per crittografare / decrittografare le e-mail e firmare con la chiave master. Il primo risiede solo sul mio PC, il secondo è distribuito su ciascun dispositivo. Finché i miei dispositivi mobili non vengono compromessi, la chiave usa e getta rimane valida.

Potrei essere eccessivamente paranoico e renderlo più complicato di quanto debba essere, ma umorizzami, per favore. Credo nel non mettere tutte le uova nello stesso paniere.

La chiave principale dovrebbe essere la mia identità digitale. Un grande sforzo verrà speso per costruire la fiducia attorno a quell'identità, e preferirei subire l'inconveniente della mia paranoia piuttosto che perdere la chiave per disattenzione e dover costruire la fiducia attorno a una nuova chiave principale (forse non è così male come me pensa, ma io sono nuovo a questo) .

Ho più probabilità di perdere il mio laptop o il mio telefono rispetto al mio PC. Se la perdita == compromette, preferirei perdere una coppia di chiavi usa e getta (che posso revocare) rispetto alla mia coppia di chiavi principale. Posso sempre concedere la fiducia della mia chiave principale su una nuova chiave usa e getta.

Ci scusiamo per la domanda davvero lunga. :-)

TL; DR

È una password di protezione sufficiente per memorizzare il mio padrone chiave privata su più dispositivi?

Il mio piano per l'opzione n. 2 è fattibile? Ho sbagliato qualcosa o può essere migliorato?

Se l'opzione 2 è una cattiva idea, quali sono le migliori pratiche quando si utilizza GnuPG per un singolo utente su più dispositivi?

Bene, questo è un po 'imbarazzante. Ho trascorso ore nel corso di una settimana a cercare di capire questo problema, e la risposta sembra trovarsi con le sottochiavi: un argomento che il manuale di GnuPG e le FAQ coprono.

Mentre cercavo cosa sono le sottochiavi e perché potrebbero essere usate al posto di --gen-key, mi sono imbattuto in questo gioiello: http://wiki.debian.org/subkeys .

Il wiki di Debian spiega come implementare l'opzione # 2 (vedi OP) usando una chiave master con sottochiavi, e spiega inoltre come rimuovere la chiave master da qualsiasi sistema dopo averla memorizzata su un supporto di backup (ad esempio un'unità flash). Le sottochiavi possono quindi essere distribuite tra i miei portachiavi su ciascun dispositivo.

Professionisti:

1. Non si basa principalmente sulla password per proteggere la chiave principale,

2. Se un sistema viene compromesso, la chiave principale non è immediatamente disponibile (a meno che non lasci stupidamente la mia unità flash collegata o collegare tale unità a un sistema compromesso),

3. Questa è una pratica implementata dal team di sviluppo di Debian.

4. Utilizza la funzione di sottochiave di GnuPG. Che sembra un po 'più organizzato che avere un mazzo di chiavi libere sul tuo portachiavi, sì?

Parte pertinente del wiki della sottochiave Debian

1. Effettua il backup dei tuoi file GnuPG esistenti ($ HOME / .gnupg). Tienili al sicuro. Se qualcosa va storto durante i seguenti passaggi, potresti aver bisogno di questo per tornare in un posto noto. (nota: umask 077 comporterà autorizzazioni restrittive per il backup.)

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

2. Crea una nuova sottochiave per la firma.

   • Trova il tuo ID chiave: gpg --list-keys yourname
   • gpg --edit-key YOURMASTERKEYID
   • Al gpg>prompt:addkey
   • Questo richiede la tua passphrase, digitala.
   • Scegli il tipo di chiave "RSA (solo segno)".
   • Sarebbe saggio scegliere la dimensione della chiave di 4096 (o 2048) bit.
   • Scegli una data di scadenza (puoi ruotare le tue sottochiavi più frequentemente delle chiavi principali o conservarle per tutta la durata della chiave principale, senza scadenza).
   • GnuPG creerà (eventualmente) una chiave, ma potresti dover aspettare che ottenga abbastanza entropia per farlo.
   • Salva la chiave: save

3. Puoi ripetere questa operazione e creare anche una sottochiave "RSA (solo crittografia)", se lo desideri.

4. Ora copia $HOME/.gnupgsulle tue unità USB.

5. Ecco che arriva la parte difficile. Devi rimuovere la chiave master privata e sfortunatamente GnuPG non fornisce un modo conveniente per farlo. È necessario esportare la sottochiave, rimuovere la chiave privata e reimportare la sottochiave.

   • Esportare le sottochiavi: gpg --export-secret-subkeys YOURMASTERKEYID >secret-subkeys(per scegliere quale sottochiavi esportare, specificare gli ID sottochiave ciascuna seguita con un punto esclamativo: gpg --export-secret-subkeys SUBKEYID! [SUBKEYID! ..])
   • Rimuovi la tua chiave segreta principale: gpg --delete-secret-key YOURMASTERKEYID
   • Importa indietro le sottochiavi: gpg --import secret-subkeys
   • Verifica che sia gpg -Kvisualizzato sec#invece di solo secper la tua chiave privata. Ciò significa che la chiave segreta non è davvero lì. (Vedi anche la presenza di un pacchetto OpenPGP fittizio nell'output di gpg --export-secret-key YOURMASTERKEYID | gpg --list-packets).
   • Facoltativamente, modificare la passphrase proteggere le sottochiavi: gpg --edit-key YOURMASTERKEYID passwd. (Si noti che il materiale della chiave privata sul backup, inclusa la chiave principale privata, rimarrà protetto dalla passphrase precedente.)

Il tuo computer è ora pronto per l'uso normale.

Quando è necessario utilizzare le chiavi master, montare l'unità USB crittografata e impostare la variabile di ambiente GNUPGHOME:

export GNUPGHOME=/media/something
gpg -K

oppure usa l'argomento della riga di comando --home:

gpg --home=/media/something -K

Quest'ultimo comando dovrebbe ora elencare la tua chiave privata con sece non sec#.

Più sottochiavi per macchina contro una singola sottochiave per tutte le macchine

Estratto dal wiki della sottochiave Debian. Originariamente notato nei commenti. [Parafrasando] ed enfatizza il mio.

Si potrebbe essere tentati di avere una sottochiave per macchina in modo che sia necessario scambiare solo la sottochiave potenzialmente compromessa di quella macchina. Nel caso di una singola sottochiave utilizzata su tutte le macchine, deve essere scambiata su tutte le macchine [quando tale singola sottochiave è o si sospetta che sia compromessa].

Ma questo funziona solo per la firma di sottochiavi . Se hai più sottochiavi di crittografia, si dice che gpg crittografa solo per la sottochiave di crittografia più recente e non per tutte le sottochiavi di crittografia note e non revocate.

Come qualcuno a cui non piacciono anche i singoli punti di errore (comprese le chiavi principali e soprattutto le password), è così che lo farei. Consente ai dispositivi di funzionare tramite una rete di fiducia, pur consentendo l'identità decentralizzata.

Non so se esiste già un sistema esistente per questo, ma penso che probabilmente potrebbe essere scarabocchiato insieme a un lavoro cron e alcune righe di Bash.

In questo sistema, esistono due classi di coppie di chiavi: coppie di dispositivi e coppie di finestre temporali . Una coppia di dispositivi viene generata per l'utente su ciascun dispositivo e rimane su quel dispositivo per tutta la sua durata. Un intervallo di tempo viene generato da un server centrale a intervalli di routine (mensile, giornaliero, orario - dipende da quanto paranoico vuoi essere). La chiave pubblica viene annunciata pubblicamente (il server stesso ha la propria coppia di dispositivi con cui firmare) e la chiave privata viene distribuita crittografata con la chiave pubblica di ciascun dispositivo che deve avere accesso a questa chiave. (Questa distribuzione dovrebbe essere il più privata possibile, ad es. Avere dispositivi collegati direttamente al server.)

Per firmare i messaggi, dovrai utilizzare il tasto del dispositivo di qualsiasi dispositivo da cui stai inviando il messaggio. Se qualcuno desidera inviarti un messaggio, può firmarlo con la tua chiave di tempo pubblica corrente. (Dovrebbero avere un sistema automatizzato per tenere il passo con gli annunci.) È quindi possibile leggere il loro messaggio da qualsiasi dispositivo.

Per la lettura di messaggi crittografati meno recenti, viene eseguito il backup delle coppie di chiavi più vecchie su ciascun dispositivo in base a una strategia appropriata (incluso il server che genera la fascia di tempo, se lo si desidera - di nuovo, a seconda del livello di paranoia), dove si dispone di un altro set di coppie di chiavi protette da password che proteggono le chiavi più vecchie (con comunque molte password nel tempo che ti senti a tuo agio nel ricordare).

Se un dispositivo viene rubato o comunque compromesso, puoi utilizzare un altro dei tuoi dispositivi di fiducia pubblica per creare un messaggio con firma pubblica che verifichi la tua identità (con qualsiasi mezzo, ad esempio notando che parteciperai a un incontro pubblico e / o avere un amico fidato che ti verifica di persona) e revocare la chiave del dispositivo compromessa e tutte le chiavi dei tempi a cui ha accesso. Quando si revoca la chiave, si rimuove anche il dispositivo rubato dall'elenco dei dispositivi attendibili del server (con una password e la chiave del dispositivo attendibile).

La politica di fiducia delle chiavi del dispositivo appena annunciate dovrebbe seguire qualcosa come le attuali politiche di fiducia: credo che una politica appropriata sia quella di fidarsi del server di generazione, di un dispositivo mobile e di un dispositivo pesante, poiché è difficile rubare / infiltrarsi il telefono di un utente, un PC desktop e VPS in un colpo concordato prima che l'utente se ne accorga.

Se il tuo server è compromesso, devi semplicemente revocarlo con la stessa procedura descritta per qualsiasi altro dispositivo compromesso (possibilmente con una politica più forte simile a quella per l'aggiunta di un nuovo dispositivo), e utilizzare un server protetto o completamente nuovo (con un nuova coppia di dispositivi) andando avanti.