Le mie chiavi private OpenPGP sono configurate con sottochiavi. Cosa succede se revoco una sottochiave e la ri-emissione di una nuova sub?

7

Ho impostato le mie chiavi OpenPGP con sottochiavi, seguendo le istruzioni generali contenute in " Creazione coppia di chiavi GPG perfetta . " L'aspetto generale è che si crea una "master keypair" che è non memorizzata sul laptop, ma su un dispositivo air-gapped sicuro. Nel mio caso, è una chiave USB crittografata. Ho anche una versione di paperkey e stampo le chiavi di revoca per la chiave principale, nel caso in cui la versione digitale venga persa o corrotta. Il mio laptop ha solo sottochiavi, non la chiave di firma principale. Di conseguenza, quando si esegue gpg -K (per visualizzare le chiavi segrete), si ottiene:

/Users/myusername/.gnupg/secring.gpg
-------------------------------
sec#  4096R/0x123412341234FFFF 2014-04-18
uid                            My Name <[email protected]>
ssb   4096R/0x123412341234AAAA 2014-04-18
ssb   4096R/0x123412341234BBBB 2014-09-24
ssb   4096R/0x123412341234CCCC 2014-09-30

Il sec# indica che la chiave di firma principale non è memorizzata sul computer. Se carico la mia chiave USB crittografata e poi eseguo gpg gpg --home=/path/to/secure/gpg/keys/.gnupg -K , mostrerebbe:

/path/to/secure/gpg/keys/.gnupg/secring.gpg
-------------------------------
sec  4096R/0x123412341234FFFF 2014-04-18
uid                            My Name <[email protected]>
ssb   4096R/0x123412341234AAAA 2014-04-18
ssb   4096R/0x123412341234BBBB 2014-09-24
ssb   4096R/0x123412341234CCCC 2014-09-30

Come vedi, mostra sec , non sec# .

In questa configurazione, se il tuo laptop è compromesso, puoi revocare le sottochiavi in modo sicuro senza perdendo qualsiasi connessione con la rete di fiducia - perché sei connesso alla rete della fiducia attraverso la tua chiave di firma principale .

Diciamo che il mio portatile è compromesso, contro cui si suppone che questo modello sia protetto. La migliore pratica, penso, sarebbe:

  1. Vai a prendere la mia chiavetta USB sicura e carica GnuPG dal portachiavi sicuro
  2. Usando la coppia di chiavi master, vorrei revocare le mie sottochiavi [perché sono ora compromesse]
  3. Ora, emetterei nuovi sottochiavi per la firma e la crittografia, e invio tutte queste modifiche ai server di chiavi pubblici.

La mia domanda è: è questa la cosa giusta da fare? Cosa succede qui esattamente, quando lo fai? Presumo che generi una nuova chiave privata / una coppia di chiavi pubbliche e invalida quella vecchia. In questo modo, se un avversario ha le mie vecchie chiavi private, in teoria possono accedere alle vecchie comunicazioni crittografate con la mia vecchia chiave pubblica. Ma non potevano firmare nulla come me, perché quella chiave privata sarebbe stata revocata. Inoltre, quando qualcuno mi controlla tramite un server delle chiavi, entrambe le vecchie e le nuove chiavi pubbliche saranno visibili, ma la vecchia chiave pubblica verrà mostrata come revocata e la nuova avrà una data più recente, quindi un utente GnuPG sta cercando di inviarmi un messaggio crittografato o un file crittografato lo crittograferà automaticamente alla chiave pubblica nuova (non revocata). E l'avversario non sarà in grado di leggere questo messaggio.

Ho ragione in tutto questo? Qualcuno può chiarire?

    
posta Jason 29.09.2015 - 20:26
fonte

1 risposta

2

My question is: Is this the right thing to do? What happens here exactly, when you do this? I presume that it generates a new private key/public key pair, and invalidates the old one. That way, if an adversary has my old private keys - they can in theory access old communications encrypted to my old public key. But they could not sign anything as me, because that private key will have been revoked. Further, when someone looks me up through a keyserver, both the old and new public keys will be visible, but the old public key will be shown as revoked and the new one will have a newer date, so a GPG user trying to send me an encrypted message or encrypted file will automatically encrypt it to the new (non-revoked) public key. And the adversary will be unable to read this message.

Hai praticamente tutto a posto; questo è esattamente il motivo per cui vengono utilizzate principalmente le sottochiavi (esistono altri casi di utilizzo accurati, a parte lo scambio di sottochiavi senza perdere la reputazione nella rete di fiducia).

Aggiungo che potrebbe esserci una data latenza: la chiave ha bisogno di un po 'di tempo (di solito minuti, meno di un'ora) per diffondere attraverso la rete di server chiavi. Se la situazione è critica e qualcuno sa che sta ascoltando la propria comunicazione, considera l'opportunità di caricarlo su diversi server nel pool di server SKS per accelerare la riconciliazione / diffusione della chiave.

Inoltre, è molto probabile che i tuoi partner di comunicazione recuperino occasionalmente gli aggiornamenti della tua chiave. Prendi in considerazione l'invio di informazioni sulle modifiche delle sottochiavi a causa di quelle vecchie compromesse; e spiega anche perché la tua chiave master è ancora salvata.

    
risposta data 29.09.2015 - 23:06
fonte